I am seriously beginning to think that where I work is cursed as far as development efforts go, I keep running into very strange issues.
I am using Roles.IsUserInRole(#"Domain\Domain Admins") to check if a user is a Domain Administrator.
For some reason, it does not recognize me in that group, although I have been in it for years. I thought at first it MIGHT have had something to do with the space, but Roles.IsUserInRole(#"Domain\Domain Users") works just fine. Both groups reside in the same AD OU.
Am I losing my mind or is there really something special about the "Domain Admins" group?
EDIT:
List<GroupPrincipal> result = new List<GroupPrincipal>();
PrincipalContext yourDomain = new PrincipalContext(ContextType.Domain);
UserPrincipal user = UserPrincipal.FindByIdentity(yourDomain, User.Identity.Name);
if (user != null)
{
PrincipalSearchResult<Principal> groups = user.GetAuthorizationGroups();
foreach (Principal p in groups)
{
if (p is GroupPrincipal)
{
result.Add((GroupPrincipal)p);
}
}
}
var myRoles = Roles.GetRolesForUser(User.Identity.Name);
I used the above code to verify group membership. Domain Admins IS listed in the result variable, but NOT in myRoles
Turns out, it has to do with elevated privledges.
Please see: https://www.reddit.com/r/csharp/comments/4cvr0p/domain_admin_is_not_showing_up_in_my_role_list_im/
(Does not explain a work around, only a reason)
Related
Question: Is it possible to determine whether an account is a service account in Active Directory using C# LDAP? If yes, how?
Context: I have a program that is retrieving all objects of schema class type USER, GROUP, COMPUTER, FOREIGN SECURITY PRINCIPAL, and CONTACT. Currently, a service account is identified by string parsing the canonical name for 'service account'. I do not like this solution because string parsing is dependent on a folder location in the hierarchy that literally says 'service account'. It seems possible that a service account could be created and then placed in a folder path that does not include the string 'service account'. Unfortunately, I cannot test this because I am not an AD admin.
I have browsed around online without any luck so I am not sure if it is even possible.
Update:
Per Microsoft, it appears that the service account is contained in objectClass msDS-ManagedServiceAccount. However, when I set the DirectoryEntry filter to msDS-ManagedServiceAccount, no results are returned.
directoryEntry = new DirectoryEntry(strActiveDirectoryHost, null, null, AuthenticationTypes.Secure);
string strDsFilter = "(objectClass=msDS-ManagedServiceAccount)";
DirectorySearcher directorySearcher = new DirectorySearcher(directoryEntry)
{
Filter = strDsFilter,
SearchScope = SearchScope.Subtree,
PageSize = intActiveDirectoryPageSize,
};
return searchResultCollection = directorySearcher.FindAll();
I have testing your code, and it does in fact return results in my environment. A few things to note:
Be sure that strActiveDirectoryHost is formatted correctly. The format should be LDAP://DC=contoso,DC=com
Check that you are searching from the root (or high enough to find the accounts you are looking for). MSAs are under the Managed Service Accounts container under the domain NC (i.e. LDAP://CN=Managed Service Accounts,DC=contoso,DC=com)
In my tests, I call new DirectoryEntry() with only the path. Not sure if passing AuthenticationTypes.Secure is causing an issue for you
The objectClass you have is correct.
So I am working on this to get the MSA as well as create them. I am able to get the MSA using the System.DirectoryServices.AccountManagement namespace, still working on creating it (unsure if this is really possible)
But for finding the accounts which are MSAs you can use the below code
PrincipalContext oPrincipalContext = new PrincipalContext(ContextType.Domain, sDomain, sDefaultOU, ContextOptions.SimpleBind, sServiceUser, sServicePassword);
GroupPrincipal currentGroup = GroupPrincipal.FindByIdentity(oPrincipalContext, "YourGroupName");
foreach (Principal a_principal in currentGroup.GetMembers())
{
if (a_principal.StructuralObjectClass == "msDS-ManagedServiceAccount")
{
Console.Write(a_principal.SamAccountName); //To get the name
ComputerPrincipal oComputerPrincipal = ComputerPrincipal.FindByIdentity(oPrincipalContext, a_principal.Name); //creating a computerprincipal to get more details about the MSA
}
}
You can use the above logic and create a Principal for the user account and get the structural object class for that account to find out if it is MSA.
Something like this:
UserPrincipal oUserPrincipal = UserPrincipal.FindByIdentity(oPrincipalContext, sUserName);
if (oUserPrincipal.StructuralObjectClass == "msDS-ManagedServiceAccount")
{
Console.Write(oUserPrincipal.SamAccountName); //To get the samaccountname
}
The following code works great for users in my domain (e.g., "TESTER" instead of "DEVELOPER"), but I can't figure out how to search higher than the current domain. I tried variation combinations of searches with the PrincipalSearcher class, but I'm not sure how to pass in a search by email address or username to look for other domains within my organization even though they're all in a single forest.
var name = "DEVELOPER\\JULIANI99";
var p = UserPrincipal.FindByIdentity(new PrincipalContext(ContextType.Domain), name);
FindByIdentity doesn't work well for searching a forest.
I tried something like this:
var d = new PrincipalContext(ContextType.Domain, "domain.com:3268", "DC=com");
var p = UserPrincipal.FindByIdentity(d, IdentityType.SamAccountName, username);
But I keep getting an error saying a referral was returned. It might be different for you. The "3268" port tells it to use the global catalog (forest-wide search). The root (which I have as "DC=com") has to be the common across all the domains in your forest. So if all your domains are sub-domains of "domain.com", then you could put "DC=domain,DC=com". But if you have "domain.com" and "otherdomain.com" part of the same AD forest, then that wouldn't work.
FindByIdentity also won't work for searching by email address, so you may just be better off using PrincipalSearcher.
If you get the same referral error I got, you can tell it to follow the referral:
PrincipalSearcher srch = new PrincipalSearcher(User);
((DirectorySearcher) srch.GetUnderlyingSearcher()).ReferralChasing = ReferralChasingOption.All;
I'm creating a PrincipalContext object for retrieving a user's groups from our AD database (we use these then for authentication to various parts of the site).
This used to be done using forms authentication, so the code looked something like this
PrincipalContext pc =
new PrincipalContext(ContextType.Domain, "domain.com", username, password);
UserPrincipal usp =
UserPrincipal.FindByIdentity(pc, IdentityType.Guid, user.Guid.ToString());
foreach (var group in usp.GetGroups())
{
// Add group to collection
}
However, we recently switched to windows authentication, and I no longer have access to the user's password.
How can I search the AD database using the current user's credentials? I've tried using impersonation, but it throws an An operations error occurred error on the FindByIdentity line. If I forget about authentication all together I'm limited in the number of groups that are returned.
Here is a method I use, You could change it to return a collection:
public static List<string> getGrps(string userName)
{
List<string> grps = new List<string>();
try
{
var currentUser = UserPrincipal.Current;
RevertToSelf();
PrincipalSearchResult<Principal> groups = currentUser.GetGroups();
IEnumerable<string> groupNames = groups.Select(x => x.SamAccountName);
foreach (var name in groupNames)
{
grps.Add(name.ToString());
}
return grps;
}
catch (Exception ex)
{
// Logging
}
}
I assume you want the results IEnumerable, which is what I did here.
Anon's answer works for what I asked, but I also wanted to be able to search for other user's groups. The best way I've found to do this is to run the asp.net program's app pool under a service account, and then use my original code.
To do this in IIS Manager 7.5, go to the Application Pools, right click on the one your app is running under -> Advanced Settings, and change the identity from "ApplicationPoolIdentity" to a custom domain account.
I have this piece of code in a program, to query what groups a Windows-domain user belongs to.
public void GetGroupNames(string userName, List<string> result)
{
using (PrincipalContext pc = new PrincipalContext(ContextType.Domain))
{
UserPrincipal uPrincipal = UserPrincipal.FindByIdentity(pc, userName);
if (uPrincipal != null)
{
PrincipalSearchResult<Principal> srcList = uPrincipal.GetGroups();
foreach (Principal item in srcList)
{
result.Add(item.ToString());
}
}
}
}
When I just implemented it and was debugging it,
UserPrincipal uPrincipal = UserPrincipal.FindByIdentity(pc, userName);
always got null.
I then had to close visual studio to do something else. When I came back, opened up visual studio, this code just worked. A few days ago, there was a network problem in the organisation, I did not switch off my PC during that period. After the network went back to normal, I could connect to internet OK, I could remote desktop to servers etc, which proves that Active Directory authentication was done all right, but the above piece of code failed to find UserPrinical for a given name, e.g. my own. I then reboot the PC, the code worked fine. I am quite puzzled regarding this matter. Is anyone able to provide a good explanation for this??
UserPrincipal has some known bugs with in cross domain scenarios. When it happens again, look and see if you can resolve groups from your machine. I have also encountered problems when unresolvable SIDs where group members.
In our system we are reading user security groups from an Active Directory in two slightly different ways. In one case the list of groups returned by the AD is missing the domain local groups. The response from GetAuthorizationGroups () is dependent on the used PrincipalContext. In the failing scenarios GetAuthorizationGroups() will only return global groups. The result is missing all domain local groups from the AD. Can anyone please explain why?
Failing solution:
PrincipalContext ctx = new PrincipalContext(ContextType.Domain, "our.domain.net");
var userPrincipal = UserPrincipal.FindByIdentity(ctx, IdentityType.UserPrincipalName, "userB");
PrincipalSearchResult<Principal> groups = userPrincipal.GetAuthorizationGroups();
In this case the process is executed by “UserA”. “UserA” is a member of the domain “our.domain.net”. “UserA” is the very same user as the specifically identified user in the working solution. The PrincipalContext should because of that be identical to the PrincipalContext in the working solution. The response from GetAuthorizationGroups() in this solution miss domain local groups from the AD.
Working solution:
PrincipalContext ctx = new PrincipalContext(ContextType.Domain, "our.domain.net", "UserA", "PasswordA");
var userPrincipal = UserPrincipal.FindByIdentity(ctx, IdentityType.UserPrincipalName, "userB");
PrincipalSearchResult<Principal> groups = userPrincipal.GetAuthorizationGroups();
In this case the calling user is identified specifically by use name and password when creating the Principal Context. In this case the AD returns all the groups that the user is a member of. This is the behavior I would like to see from the failing solution as well. In some cases I do not have the user password of UserA and of that reason the Working solution is not an option.
Please help me understand why the failing solution does not return all the groups that the user is a member of.
"It misses domain local groups from the AD" because you are probably iterating the resulting groups with foreach loop and you are getting NoMatchingPrincipalException exception for one of the groups that the user doesnt have read access and at that point it stops iterating, failing to get the rest of the groups.
As a solution you may use the following iterator (the code behind the foreach structure) to get all the rest of the groups:
var enumerator = groups.GetEnumerator();
while (enumerator.MoveNext())
{
try
{
var e = enumerator.Current;
listView1.Items.Add(e.Name);
}
catch (NoMatchingPrincipalException)
{
}
}
We finally found the problem. It turned out not to be a coding problem at all. The strange behaviour was caused by an erronious Domain Level in the Active Directory.
Domain Level had to be set to "2003 functional level"
Now it all works as expected.