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
}
Related
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 >
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 need to get the Display Name of the current user, and cannot find a solution that always works. Just for clarity, I'm not looking for the username. I need the "John Doe". The value displayed on the Start Menu.
There are many posts about this question however none have solved my problem.
Get Windows User Display Name
How do I get the AD Display Name of the currently logged in user
These two posts lead me to:
PrincipalContext context = domain.Equals(Environment.MachineName, StringComparison.CurrentCultureIgnoreCase) ?
new PrincipalContext(ContextType.Machine) :
new PrincipalContext(ContextType.Domain, domain);
UserPrincipal userPrincipal = new UserPrincipal(context) { SamAccountName = username };
PrincipalSearcher searcher = new PrincipalSearcher(userPrincipal);
userPrincipal = searcher.FindOne() as UserPrincipal;
string displayName = userPrincipal.DisplayName;
And this code works for the most part. However if the user's has disabled/stopped the Server service on his/her computer I get an exception saying "The Server service is not started."
System.DirectoryServices.AccountManagement.UserPrincipal.Current.DisplayName
Same error.
How to get logged-in user's full name in windows?
StringBuilder name = new StringBuilder(1024);
uint userNameSize = (uint)name.Capacity;
const int NameDisplay = 3;
GetUserNameEx(NameDisplay, name, ref userNameSize)
Returns no error, but an empty string if the user is not on a domain.
How do you read the user's display (first and last) name on all versions of Windows reliably?
// get SAM compatible name <server/machine>\\<username>
if (0 != GetUserNameEx(2, username, ref userNameSize))
{
IntPtr bufPtr;
try
{
string domain = Regex.Replace(username.ToString(), #"(.+)\\.+", #"$1");
DirectoryContext context = new DirectoryContext(DirectoryContextType.Domain, domain);
DomainController dc = DomainController.FindOne(context);
if (0 == NetUserGetInfo(dc.IPAddress,
Regex.Replace(username.ToString(), #".+\\(.+)", "$1"),
10, out bufPtr))
{
var userInfo = (USER_INFO_10) Marshal.PtrToStructure(bufPtr, typeof (USER_INFO_10));
return Regex.Replace(userInfo.usri10_full_name, #"(\S+), (\S+)", "$2 $1");
}
}
finally
{
NetApiBufferFree(out bufPtr);
}
}
With the above I get an ActiveDirectoryObjectNotFoundException with message "Domain controller not found in the domain.." when DomainController.FindOne is called.
I haven't found a registry setting for the display name.
I'm don't know what else to try. Please help.
All of the above methods will only work if you are on a domain. If you are not, then you must rely on the local user account store. The following details how to retrieve this info: How can I get a list Local Windows Users (Only the Users that appear in the windows Logon Screen). In a domain situation though, the users account will not be in the local store.
If you are on a domain but not connected to the domain controller, the Display Name will not be readily available to you. This information is stored on the domain controller, not the local user's computer. If your users are on a domain, they really shouldn't be able to disable the Server service(use GPOs). Also, they lose much more than the ability to retrieve their user account by disabling that service.
I would check for domain availability before trying to get the display name. If it fails, display a message indicating the failure. There are potentially too many edges cases here to make it work accounting for all of them. Go with the scenario that you intend the program to be used under, and give an error message for the others.
while enumerating current user's groups through AD .NET API I sometimes get
COMException: Unknown error (0x80005000)
Here's my code :
var userName = Environment.UserName;
var context = new PrincipalContext(ContextType.Domain);
var user = UserPrincipal.FindByIdentity(context, userName);
foreach (var userGroup in user.GetGroups())
{
Console.WriteLine(userGroup.Name);
}
What's the problem? I thought every user can retrieve list of HIS groups?It seems to be strange behavior, sometimes It can be reproduced like this : when running on 'userA' PC, It crashes, but it is enumerating OTHER 'userB' groups successfully (under 'userA')!
Try using
var context = new PrincipalContext(ContextType.Domain, "yourcompany.com", "DC=yourcompany,DC=com", ContextOptions.Negotiate);
With the ContextOption set to Negotioate the client is authenticated by using either Kerberos or NTLM so even if the user name and password are not provided the account management API binds to the object by using the security context of the calling thread.
I had the same problem, I solved it by supplying the domain name when creating the PrincipalContext:
var domain = new PrincipalContext(ContextType.Domain, Environment.UserDomainName);
var user = UserPrincipal.FindByIdentity(domain, Environment.UserName);
0x80005000 = E_ADS_BAD_PATHNAME so you supply an invalid adspath somewhere, maybe you must add LDAP:// prefix or opposit are doing this twice? Set a breakpoint and inspect value...
EDIT:
AdsPath should be a value like "LDAP://CN=Administator,CN=Users,DC=contoso,DC=com", you seem to have a misformed path.
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.