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.
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
The reason is guaranteed security. The samAccountName attribute is unique across all security principal objects in an NTDS domain. If other name attribute would be used instead an attacker could easily workaround security permission by creating other user/group with the same name in a different organizational unit or container.
