I try to authenticate users belonging to remote ActiveDirectory from my machine, which is not the same domain as the current machine or user domain. There will be no trust between my machine and remote ActiveDirectory machine.
Initial Try
I tried to authenticate a user(Input: sAMAccountName, machine's ipaddress, machine's domain username("Administrator") and machine's password(***). Able to get result that the user with 'sAMAccountName' do exist in ActiveDirectory.
My Requirement:
Imagine that already a user("qwerty") is created in ActiveDirectory
From my local machine, I will have the following information,
a. Remote ActiveDirectory ipaddress
b. Remote ActiveDirectory machine's username and password.
c. Username and password of User "qwerty"
I need to check whether User "qwerty" is present in remote ActiveDirectory's users list and validate whether the password entered is same in ActiveDirectory's Users list
Code I tried:
DirectoryEntry entry = new DirectoryEntry("LDAP://ipaddress/DC=dinesh,DC=com", name, password);
DirectorySearcher searcher = new DirectorySearcher(entry);
searcher.Filter = "(sAMAccountName=" + name + ")";
try
{
SearchResult adsSearchResult = adsSearcher.FindOne();
isValid = true;
adsEntry.Close();
}
catch (Exception ex)
{
adsEntry.Close();
}
Do I need to create a trust between local machine and remote ActiveDirectory machine before validating Users in a remote ActiveDirectory? If yes please tell how it can be done;
After creating trust, how can I validate Users?
===========================================================================
I am able to use the solution suggested by Rainer, but with a new problem. When I create a new user via C# code from a different machine, then some properties do not set properly.
Does this need to be set compulsorily while creating user?
First some basics (independent of this question)
Authentication
The system checks if Bob is really Bob. In an Active Directory environment, this is usually done with a domain login from the workstation, Bob enters his username and password, and he gets a Kerberos ticket. Later, if he wants to access e.g. a file share on a remote fileserver, he does not need to login anymore, and can access the files without entering username/password.
Authorization
The system checks which resources Bob is allowed to access. Usually Bob is in domain groups, and a group is in the ACL (access control list) of the resource.
If there are multiple trusting domains, Bob needs to login in one domain, and can access resources in all other domains.
This is one of the main reasons using Active Directory: single sign on
Checking if user / password is valid
If you have a username and password and want to check if the password is valid, you have to do a login to the domain. There is no way of just “checking if the password is correct”.
Login means: if there is a security policy “lock account if more than 3 invalid logins”, the account will be locked out checking with wrong password, even if you “only want to check the user+password”.
Using .NET Directory Service functions
I assume here that the process is either run by a human account as a normal program, or the program is a Windows service or a scheduled task which runs under a domain “technical user” account. In this case, you do not need to provide credentials for using the AD functions. If accessing other trusting AD domains, this is also true.
If you want to login to a “foreign domain”, and there is no trust, you need to provide a username+password (as in your code).
"Manually" authenticating a user
Normally, this should not be needed. Example: ASP.NET intranet usage. The user access a web application on the current domain or trusting domain, the authentication is done “in the background” by browser and IIS (if integrated Windows authentication is on). So you never need to handle user passwords in the application.
I don’t see many use cases where a password is handled by code.
One may that your program is a helper tool for storing emergency user accounts/passwords. And you want to check periodically if these accounts are valid.
This is a simple way to check:
using System.DirectoryServices.AccountManagement;
...
PrincipalContext principalContext =
new PrincipalContext(ContextType.Domain, "192.168.1.1");
bool userValid = principalContext.ValidateCredentials(name, password);
One can also use the older, raw ADSI functions:
using System.DirectoryServices;
....
bool userOk = false;
string realName = string.Empty;
using (DirectoryEntry directoryEntry =
new DirectoryEntry"LDAP://192.168.1.1/DC=ad,DC=local", name, password))
{
using (DirectorySearcher searcher = new DirectorySearcher(directoryEntry))
{
searcher.Filter = "(samaccountname=" + name + ")";
searcher.PropertiesToLoad.Add("displayname");
SearchResult adsSearchResult = searcher.FindOne();
if (adsSearchResult != null)
{
if (adsSearchResult.Properties["displayname"].Count == 1)
{
realName = (string)adsSearchResult.Properties["displayname"][0];
}
userOk = true;
}
}
}
If your real requirement is actually a validity check of user+password, you can do it in one of these ways.
However, if it is a "normal application", which just wants to check if the entered credentials are valid, you should rethink your logic. In this case, you better should rely on the single sign on capabilities of AD.
If there are further questions, please comment.
b. Remote ActiveDirectory machine's username and password.
This sounds a bit unclear. I assume you mean "a username and corresponding password in the remote domain".
There is also the concept of a machine account, which is the hostname appended with $. But that's another topic.
Creating new user
Option 1
using (DirectoryEntry directoryEntry = new DirectoryEntry("LDAP://192.168.1.1/CN=Users,DC=ad,DC=local",
name, password))
{
using (DirectoryEntry newUser = directoryEntry.Children.Add("CN=CharlesBarker", "user"))
{
newUser.Properties["sAMAccountName"].Value = "CharlesBarker";
newUser.Properties["givenName"].Value = "Charles";
newUser.Properties["sn"].Value = "Barker";
newUser.Properties["displayName"].Value = "CharlesBarker";
newUser.Properties["userPrincipalName"].Value = "CharlesBarker";
newUser.CommitChanges();
}
}
Option 2
using (PrincipalContext principalContext = new PrincipalContext(ContextType.Domain, "192.168.1.1",
"CN=Users,DC=ad,DC=local", name, password))
{
using (UserPrincipal userPrincipal = new UserPrincipal(principalContext))
{
userPrincipal.Name = "CharlesBarker";
userPrincipal.SamAccountName = "CharlesBarker";
userPrincipal.GivenName = "Charles";
userPrincipal.Surname = "Barker";
userPrincipal.DisplayName = "CharlesBarker";
userPrincipal.UserPrincipalName = "CharlesBarker";
userPrincipal.Save();
}
}
I leave as an exercise to you to find out which attribute goes into which User dialog entry field :-)
Related
I am trying to run my password change application from a non domain joined machine. The code works fine when run from domain joined machine. So now, I am connecting to the AD with direct LDAP connection via SSL. After changepassword method is invoked, I am getting an error:
Configuration information could not be read from the domain controller, either because the machine is unavailable, or access has been denied. (Exception from HRESULT: 0x80070547).
I am making the connection and running the application using a service account with permission to change user passwords.
string adminUser = Domain + #"\" + AdminUserName;
string adminPass = AdminUserPassword;
string ldapString = LDAPString;
DirectoryEntry de = new DirectoryEntry(ldapString, adminUser, adminPass, AuthenticationTypes.Secure);
DirectorySearcher deSearch = new DirectorySearcher(de) { SearchRoot = de, Filter = "(&(objectCategory=user)(cn=" + userName + "))" };
SearchResult result = deSearch.FindOne();
if (result != null)
{
var adContext = new PrincipalContext(ContextType.Domain);
currentdc = adContext.ConnectedServer;
DirectoryEntry userEntry = result.GetDirectoryEntry();
if (userEntry != null)
{
userEntry.Invoke("ChangePassword", new object[] { OldPassword, NewPassword });
}
}
Invoking ChangePassword, calls IADsUser::ChangePassword. That documentation says it works much the same as IADsUser::SetPassword. That documentation has more information. Really, only the first method would work when you're running this from outside the domain:
First, the LDAP provider attempts to use LDAP over a 128-bit SSL connection. For LDAP SSL to operate successfully, the LDAP server must have the appropriate server authentication certificate installed and the clients running the ADSI code must trust the authority that issued those certificates. Both the server and the client must support 128-bit encryption.
I assume your LDAPString is in the format LDAP://example.com:636 (the :636 being the important part). If you can read data like that, then the SSL certificate is trusted. So that's good.
The only maybe missing piece could be 128-bit encryption? Check the certificate and see if it's maybe using less than 128-bit. Although I'd be surprised if it did.
This answer has a short snippet of code that you can use to download a certificate from any site: https://stackoverflow.com/a/22251597/1202807
Just use "https://example.com:636" as the "website".
There is also this:
In Active Directory, the caller must have the Change Password extended control access right to change the password with this method.
You should make sure that the user account you are authenticating to LDAP with does have the Change Password permission on the account you are trying to update. In our environment, Everyone has the Change Password permission (since you still need to provide the old password to do it). I think that's the default, but it's worth checking.
I want to make a few simple reports from Active Directory. Following discussions, etc. I found that if I use .NET FW 3.5 and up, it is appropriate to use PrincipalContext. I would like to understand principles and what I can do with this new feature (unlike DirectoryEntry).
Code skeleton
// create your domain context
PrincipalContext ctx = new PrincipalContext(ContextType.Domain,
"YOURDOMAIN", "OU=SomeOU,DC=YourCompany,DC=com");
// define a "query-by-example" principal - here, we search for a UserPrincipal
// which has a password that will expire in 3 days or less
UserPrincipal userTemplate = new UserPrincipal(ctx);
userTemplate.AdvancedSearchFilter.AccountExpirationDate(DateTime.Today.AddDays(3), MatchType.LessThanOrEquals);
// instantiate searcher
PrincipalSearcher searcher = new PrincipalSearcher(userTemplate);
// enumerate matching users
foreach (Principal foundPrincipal in searcher.FindAll())
{
UserPrincipal foundUser = (foundPrincipal as UserPrincipal);
if (foundUser != null)
{
// do something with users found - e.g. send e-mail
}
}
It is possible by code up add this properties for login to LDAP?:
what LDAP is used (version 2 or 3)
how set port on which LDAP is running
how to work if I need SSL connection? (different port, must be special requirements)
Furthermore, can I do with AdvancedSearchFilter this conditions?
(I found only AccountExpirationDate and AccountLockoutDate)
users password will expire in the near future
users password has expired
check if the user's password can expire
users account expires (account, no password)
expired users account (account, no password)
user account not expired
sorry for the late reply. The solution I found these two links, which describes all the information. Just as it only needs to combine with the code above.
retrieve the value of "Minimum Password Length" in domain password policy
House of Derek - Password expiration email utility
I am having some difficulty with doing an automated login for users in my desktop Active Directory application. I may be trying to do an SSO, but I am under the impression that is only for web applications.
The code I have, is this:
PrincipalContext theContext = new PrincipalContext(ContextType.Domain);
if (theContext.ValidateCredentials(null, null))
Console.WriteLine("Credentials have been validated. Tell your friends.");
else
Console.WriteLine("Invalid credentials");
UserPrincipal user = new UserPrincipal(theContext, "uatu", "Passw0rd", true);
user.Save();
The PrincipalContext is being created without error, and I am validating the credentials. I assumed this would validate me as the user that logged in to the computer, which is under the Active Directory domain. And I can find users and groups. But as soon as I call user.Save() I get the error "Access is denied." Am I actually getting into Active Directory as a guest user?
If I set the user name and password in ValidateCredentials, it doesn't help.
PrincipalContext theContext = new PrincipalContext(ContextType.Domain);
if (theContext.ValidateCredentials("<username>", "<password", ContextOptions.Negotiate | ContextOptions.Signing | ContextOptions.Sealing))
Console.WriteLine("Credentials have been validated. Tell your friends.");
else
Console.WriteLine("Invalid credentials");
UserPrincipal user = new UserPrincipal(theContext, "uatu", "Passw0rd", true);
user.Save();
That code still fails on user.Save().
If I explicitly set the username and password to match myself as the logged in user in the PrincipalContext constructor, then I get success.
PrinicipalContext theContext = new PrincipalContext(ContextType.Domain,"<address>", "<domain context>", "<username>", "<password>");
UserPrincipal user = new UserPrincipal(theContext, "uatu", "Passw0rd", true);
user.Save();
That code succeeds. But I would rather not have the user log in to my application after they have logged into their computer with the exact same credentials.
I have been hearing a bit about "Affiliate Application", so I'm wondering if I have to let Active Directory know that it can trust my application. I am still hazy on the details through, and don't know if that is the wrong direction.
Does anyone have an idea as to what I should be doing?
If you are trying to modify UserPrincipals, you have a couple options:
User is already authenticated to windows as a user with permission to edit active directory:
Use the Constructor for PrincipalContext which doesn't take username/password
This will run the context as the currently logged in user
Run query, var usr = UserPrincipal.FindByIdentity(ctx, "bob#domain.local");
Perform manipulations on usr object
Call usr.Save(); on the returned user from the query.
User is authenticated to windows, but you must "impersonate" a user with AD permission
Use the Constructor for PrincipalContext which takes username/password
This will run the context as the credentials you passed in
Run query, var usr = UserPrincipal.FindByIdentity(ctx, "bob#domain.local");
Perform manipulations on usr object
Call usr.Save(); on the returned user from the query.
Based on your explanation above, I'm presuming you need option #1. ValidateCredentials(); is only used to validate credentials, it returns a true/false if the credentials you've given it are valid. Calling it has no lasting affect, it only validates. If you need to impersonate a user, you need to use the PrincipalContext constructor which takes credentials.
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.
I am trying to authenticate users to active directory with the Novell.Directory.Ldap libraries found in Mono. I know there is better ways than below, but given that I'm confined to Mono, these are the only supported routines as best I can see.
Using the .NET libraries, I can authenticate a user with their samAccountName.
using (DirectoryEntry de = new DirectoryEntry())
{
de.Username = username;
de.Password = password;
de.Path = string.Format("LDAP://{0}/{1}", ADHostname, DefaultNamingContext);
de.AuthenticationType = AuthenticationTypes.Secure;
using (DirectorySearcher deSearch = new DirectorySearcher())
{
deSearch.SearchRoot = de;
deSearch.PropertiesToLoad.Add("cn");
deSearch.Filter = "(&(objectCatagory=person))";
deSearch.FindOne();
}
}
but this fails with invalid credentials if it's running inside mono. The only way to make it work is by specifying the UPN for username:
de.Username = "foo#my.domain.com";
The problem is, UPN is not a required attribute for AD. So how can I authenticate a user with just their username?
I see a post about one way to do it: Authenticating user using LDAP from PHP
But, it's a chicken and egg problem. How do I bind to search for the users DN so I can bind, if I can't bind as an authenticated user to begin with.
Thank you for any help you can give.
Usually you get an account for your application to allow the search for other user DN's. Traditionally this was done using an anonymous bind, but nowadays that is usually blocked for security reasons.
Therefore get a service account with a known DN and password. Bind as that service account, do your search, then bind as the users DN that you found via the search.