>>Yep, and it uses NetFileEnum(), as mentioned by Pat Boens. It -can- be done programmatically
>
>I know (see my last FAQ for the code :)).
>
>>but access to it requires that the user is a member of the Administrators or Account Operators
local group.
>
>It's the same for the Network Watch program. Internally, it uses NetFileEnum too.
>
>Anyway, user accounts on one domain can be members of a local group on another domain. I believe the requirement for administrative rights is normal in the context of Win NT security.
Yes, but from the standpoint of domain administration, it's a major PITA to explicitly grant local admin rights to domain admin members of trusted domains.
>
>>It's also a bit cumbersome to program (you specify the server and base path, and then spin through using a resume handle.
>
>Specifing an empty string (or NULL in C++) for the server, it returns all servers. Empty string for the base path: all files. Empty string for the user: all users. From this point of view is good enough, IMHO.
>
>>You can't tell it to return info on just a single file, and you must know the
local path;
>
>You can specify a single file and it works. It's true that the local path and not the share is required. :(
>
>>IOW, knowing the share doesn't help (the UNC or mapped drive path on another machine is no help, you have to specify things in the server's local context.)
>
>NetShareGetInfo() Win32API can be used to get the local path from the share/net path.
NetShareGetInfo() has the same security requirements as NetFileEnum() if you want to get back local path information; you need to retrieve either SHARE_INFO_2 or SHARE_INFO_502 structures to retrieve the local path. And at least according to the docs, you need local admin or account operator group membership, or the user needs to be a member of a resource operator group at the domain level.
>
>>When you're logged into the system via a domain login, you get back
ERROR_ACCESS_DENIED fairly often, even if the user has a valid account on the system. You have to be logged into the account on the NT box machine locally, and not onto the domain to make it work.
>
>What does "fairly often" means? Sometimes it works, sometimes it doesn't?
It depends largely on the domain architecture - in single server and single master environments, a domain admin account will be able to access the API call on all servers, Win95/98 boxes regardless of share method, and NT Workstation boxes that grant local admin rights to domain administrators. Go to a multiple domain environment, and things change - domain admins may not be able to access the API for shares on resource domains that have a trust relationship to the master domain. I haven't figured out why; I suspect that it has to do with inherited rights across a trust, but I haven't explored it in detail. It's largely an issue for users in large-scale network environments - most small to mid-size businesses don't need to have multiple domains with complex domain trust relationships.
As long as it's understood that the API is only going to work in a narrow security context, all is well with the world; if users with normal account rights want to see who has the file open, the information isn't readily available to them directly through this API.
>
>Vlad
