Getting the properties of a DirectoryEntry (local user) in c# whenthe user is a domain account? Acti

[Michael Howes]

I'm writing a utility to manage a machines *local* accounts in c#

I am getting all the users in a specific Group just fine but when I
want to get some of the information on each user from their Properties
collection I can't get the properties on some users.

For example, I get all the users that are part of my machines
Administrators Group. I get get the properties of the built in local
Administrator account and some local IT account, and the Domain Admins
account but some of the users, I think the users that are on the domain
(I'm not sure) that are added to the local group throw an "Access is
denied" error when trying to do something like this;

if (user.Properties["Description"].Value != null)
lbUsers.Items.Add(user.Properties["Description"].Value.ToString());

I'm getting these users using this code;
DirectoryEntry localMachine = new DirectoryEntry("WinNT://" +
Environment.MachineName + ",Computer");

DirectoryEntry admGroup = localMachine.Children.Find("Administrators",
"group");

object members = admGroup.Invoke("members", null);

anybody have any ideas?
thanks
mike



PS If you want to reply directly instead of on the group, remove the x
from my email address. I get enough spam as it is and found when I post
to these groups my spam nearly doubles.

 

[Joe Kaplan]

Are you logged in with a local machine account or a domain account when you
do this? Perhaps you don't have domain creds and therefore don't have
permission to read values out of AD? AD typically doesn't allow
unauthenticated users to query it. You get a different error with the LDAP
provider (which is what I'm more familiar with), but the error you are
getting with WinNT makes sense to me in this context.

Joe K.

 

[Michael Howes]

Are you logged in with a local machine account or a domain account when you

do this? Perhaps you don't have domain creds and therefore don't have
permission to read values out of AD? AD typically doesn't allow
unauthenticated users to query it. You get a different error with the LDAP
provider (which is what I'm more familiar with), but the error you are
getting with WinNT makes sense to me in this context.

I'm logged in with a domain account that has admin privileges on this
machine.
I can check with our IT guy and see what domain creds (probably not
many) I have. The easy test would be to have him log into my machine and
run it as him.

thanks
mike

 

[Joe Kaplan]

Generally speaking, if you are logged in as a domain user, I'd expect your
account to be able to read these properties, so something else might be
wrong. However, it is pretty hard to say what the issue is. I wonder if
you would be able to read these attributes with the LDAP provider connecting
back to the domain.

Joe K.

 

[Michael Howes]

Generally speaking, if you are logged in as a domain user, I'd expect your
account to be able to read these properties, so something else might be
wrong. However, it is pretty hard to say what the issue is. I wonder if
you would be able to read these attributes with the LDAP provider connecting
back to the domain.

I noticed that the DirectoryEntry constructor takes name, password,
and authentication type.
I assume I can use those and prompt for an domain admin name/pswd?

I just tried it, asked our IT guy to login as domain admin and it
wouldn't login and gave a COM exception.

But this is a bit odd, I'm trying to connect to the local machine with
a domain admin login?
I'm really out of my element here and really am guessing at this point.

Even looking at the user's DirectoryEntry object I can see that some
properties like Guid, say "UnauthorizedAccessException"

So how does one use the name/password/authentication type of the
DirectoryEntry constructor to pass in a name/password of of someone who
has domain admin privileges? and is his the correct way to be thinking
about this?

thanks
mike

 

[Joe Kaplan]

That should work in general. The WinNT provider can be a little less
reliable than the LDAP provider when providing credentials, but it should
work in most cases.

Typically, you should be able to supply a username via "domain\user", a
password and AuthenticationTypes.Secure. If that doesn't work, let us know
what the actual COMException details were.

Joe K.