Develop Reference

Why can I find OUs using 'new DirectoryEntry(guid)' but not Principle.FindByIdentity?

I am trying to locate the user accounts for our store locations using DirectoryServices.AccountManagement in .NET Core 2.1.
If I just new up a DirectoryEntry using the OU's guid it pulls the entry back no problem. But as soon as I try using the AccountManagement principal, it always returns null for the store's user account.
Each store location also has a distribution group as well, and I am able to locate those using Principal.FindByIdentity, just not the actual user account for the store.
using (PrincipalContext pc = new PrincipalContext(ContextType.Domain, _domainName, _username, _password))
{
// returns null
var testOU = Principal.FindByIdentity(pc, IdentityType.Guid, store.ActiveDirectoryOU.ToString());
// returns proper DirectoryEntry for store's User Account
var testEntry = new DirectoryEntry("LDAP://<GUID=" + store.ActiveDirectoryOU + ">");
// returns proper Principal for store's distribution group
var testGroup = Principal.FindByIdentity(pc, store.ActiveDirectoryGroup.ToString());
}
Is there some sort of setting that prevents certain user accounts from being visible to DirectoryServices.AccountManagement? Or am I making some newb mistake?

You are using Principal.FindByIdentity rather than UserPrincipal.FindByIdentity to get the specific users. Is it possible that this could be the issue?
See this example.
See also >

Active Directory: How to determine whether account is service account?

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
}

Unable to extract information

I'm trying to query a domain to determine if:
User is a valid user (and has the correct password)
User is enabled
User belongs to group x
My development machine does not belong to this domain.
I want to specify the username and password via my application
I'm using the System.DirectoryServices.AccountManagement namespace as this seems to be the most efficient way doing this, however I've struggling to get even the most basic of information out of my domain controller.
I can explore LDAP via another tool.
First test is to collect user information, the code below returns null on user.
The user however is valid.
What am I doing wrong?
// set up domain context
PrincipalContext ctx = new PrincipalContext(ContextType.Domain, "server","CN=Users,DC=doom,DC=home", "ldapuser","password");
// get user contect
UserPrincipal user = UserPrincipal.FindByIdentity(ctx, IdentityType.Name, username);
//is user locked?
var locked = user.Enabled;
Update:
Having defined the bind method as below, I now receive error
"Information about the domain could not be retrieved (1355)."
var ctx = new PrincipalContext(ContextType.Domain, "server", "DC=doom,DC=home", ContextOptions.SimpleBind, "ldapuser", "password");

Sorted.
This answer resolves the two issues I came across when attempting to connect to a domain controller that I am not a member of.
This article get me the final answer:
http://elegantcode.com/2009/03/21/one-scenario-where-the-systemdirectoryservices-accountmanagement-api-falls-down/
you need to define the Bind in the context (i.e. ContextOptions.SimpleBind)
You must set up the domain server in your Network adaptors DNS settings as the first DNS server to use.
I can now connect to my AD and collect data.

Read user authorization groups from Active Directory

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.

Active Directory: Get RootDSE in domain residing in Forest with multiple roots?

I have a client that's utilizing a windows service I wrote that polls a specified active directory LDAP server for users in specified groups within that LDAP server.
Once it finds a user, it fills out the user information (i.e. username, email, etc.) and attempts to retrieve the user's domain within that LDAP server.
When I attempt to retrieve the user's domain for this specific client, I'm hitting a DirectoryServicesCOMException: Logon failure: unkonwn user name or bad password.
This exception is being thrown when I attempt to reference a property on the RootDSE DirectoryEntry object I instantiate.
This client has a Forest with two roots, setup as follows.
Active Directory Domains and Trusts
ktregression.com
ktregression.root
I assume this is the issue.
Is there any way around this? Any way to still retrieve the netbiosname of a specific domain object without running into this exception?
Here is some sample code pointing to a test AD server setup as previously documented:
string domainNameLdap = "dc=tempe,dc=ktregression,dc=com";
DirectoryEntry RootDSE = new DirectoryEntry (#"LDAP://10.32.16.6/RootDSE");
DirectoryEntry servers2 = new DirectoryEntry (#"LDAP://cn=Partitions," + RootDSE.Properties["configurationNamingContext"].Value ); //*****THIS IS WHERE THE EXCEPTION IS THROWN********
//Iterate through the cross references collection in the Partitions container
DirectorySearcher clsDS = new DirectorySearcher(servers2);
clsDS.Filter = "(&(objectCategory=crossRef)(ncName=" + domainNameLdap + "))";
clsDS.SearchScope = SearchScope.Subtree;
clsDS.PropertiesToLoad.Add("nETBIOSName");
List<string> bnames = new List<string>();
foreach (SearchResult result in clsDS.FindAll() )
bnames.Add(result.Properties["nETBIOSName"][0].ToString());

It seems that the user account with which the Active Directory tries to authenticate "you" does not exist as your DirectoryServicesCOMException reports it.
DirectoryServicesCOMException: Logon failure: unkonwn user name or bad password.
Look at your code sample, it seems you're not using impersonation, hence the security protocol of the Active Directory take into account the currently authenticated user. Make this user yourself, then if you happen not to be defined on both of your domain roots, one of them doesn't know you, which throws this kind of exception.
On the other hand, using impersonation might solve the problem here, since you're saying that your Windows Service account has the rights to query both your roots under the same forest, then you have to make sure the authenticated user is your Windows Service.
In clear, this means that without impersonation, you cannot guarantee that the authenticated user IS your Windows Service. To make sure about it, impersonation is a must-use.
Now, regarding the two roots
ktregression.com;
ktregression.root.
These are two different and independant roots. Because of this, I guess you should go with two instances of the DirectoryEntry class fitting one for each root.
After having instantiated the roots, you need to search for the user you want to find, which shall be another different userName than the one that is impersonated.
We now have to state whether a user can be defined on both roots. If it is so, you will need to know when it is better to choose one over the other. And that is of another concern.
Note
For the sake of simplicity, I will take it that both roots' name are complete/full as you mentioned them.
private string _dotComRootPath = "LDAP://ktregression.com";
private string _dotRootRootPath = "LDAP://ktregression.root";
private string _serviceAccountLogin = "MyWindowsServiceAccountLogin";
private string _serviceAccountPwd = "MyWindowsServiceAccountPassword";
public string GetUserDomain(string rootPath, string login) {
string userDomain = null;
using (DirectoryEntry root = new DirectoryEntry(rootPath, _serviceAccountLogin, _serviceAccountPwd))
using (DirectorySearcher searcher = new DirectorySearcher()) {
searcher.SearchRoot = root;
searcher.SearchScope = SearchScope.Subtree;
searcher.PropertiesToLoad.Add("nETBIOSName");
searcher.Filter = string.Format("(&(objectClass=user)(sAMAccountName={0}))", login);
SearchResult result = null;
try {
result = searcher.FindOne();
if (result != null)
userDomain = (string)result.GetDirectoryEntry()
.Properties("nETBIOSName").Value;
} finally {
dotComRoot.Dispose();
dotRootRoot.Dispose();
if (result != null) result.Dispose();
}
}
return userDomain;
}
And using it:
string userDomain = (GetUserDomain(_dotComRoot, "searchedLogin")
?? GetUserDomain(_dotRootRoot, "searchedLogin"))
?? "Unknown user";
Your exception is thrown only on the second DirectoryEntry initilization which suggests that your default current user doesn't have an account defined on this root.
EDIT #1
Please see my answer to your other NetBIOS Name related question below:
C# Active Directory: Get domain name of user?
where I provide a new and probably easier solution to your concern.
Let me know if you have any further question. =)

I believe that the DirectoryEntry has properties to specify for an AD account that can perform LDAP queries or updates, you can also delegate that control down from your parent domain.