views:

176

answers:

1

This is more of a curiosity than a request for help, but I noticed that when using PrincipalPermission and verifying a user is part of a specific group in Active Directory it will not use the true group name but instead validates against the pre-Windows 2000 group name instead. Ordinarily this wouldn't make a difference - unless someone happens to make these values different.

Can anyone think of why the .Net API would use that group name instead of the "true" name? This caused me hours of grief and a bit of blind luck to finally figure it all out.

+1  A: 

I would assume (without having tested and tried this myself) that the PrincipalPermission attribute will use the "sAMAccountName" in Active Directory for user and group names (e.g. "Users" or "JohnDoe") instead of the "distinguished name" (DN) you might expect ("CN=Users", "CN=John Doe").

The reasoning behind this will most likely be the scenario where you're working on e.g. a stand-alone server, or a NT4 domain. In those cases, you simply don't have any AD-based distinguished names - but you do have the SAM account names.

So in a sense this might seems a bit surprising at first - but it does make sense in my opinion to use those SAM account names (pre-AD names) - don't you agree?

Marc

marc_s
Interesting. I think I can see what you mean - they do this to support the clients who may run something on a system without Active Directory. I didn't even realize the group names would still be something like "sAMAccountName" on a local system (never tried it before to be honest).Thanks!
digitall