I want to create a ldap account (with password) or change account passwords with spring-ldap, so I follow some instructions to export a certificate from AD and import it to jdk, after that I change the protocol and port of the url to ldaps://AD-SERVER-TEST.test.com:636, I think It's all I have to do. But I got a javax.naming.OperationNotSupportedException: [LDAP: error code 53 - 00002077: SvcErr: DSID-031908B4, problem 5003 (WILL_NOT_PERFORM), data 0 error. It means spring-ldap doesn't connect AD through secure connection.
I search from the web, nothing help. But I can change the password with native ldap support, for example , javax.naming.ldap.InitialLdapContext.createSubcontext() to create a new account, all the ldap config is the same as spring-ldap. So do I need make more changes to spring-ldap ?
the native ldap enviroment config like this, nothing special:
env.put(Context.INITIAL_CONTEXT_FACTORY, "com.sun.jndi.ldap.LdapCtxFactory");
env.put(Context.SECURITY_AUTHENTICATION, "simple");
env.put(Context.SECURITY_PRINCIPAL, adminName);
env.put(Context.SECURITY_CREDENTIALS, adminPassword);
env.put(Context.SECURITY_PROTOCOL, "ssl");
String ldapURL = "ldaps://AD-SERVER-TEST.test.com:636";
env.put(Context.PROVIDER_URL, ldapURL);
I am trying to open a gpmc for another domain. We have 2 AD Domains A and B. There are no trusts between them. My Computer is joined to Domain A and I want to open a gpmc for domain B.
For DSA (AD Users and Computers) this seems to be possible like this:
runas.exe /netonly /user:<Domain B>\<Domain B User> "mmc dsa.msc /domain=<Domain B>"
but when I try to run this for gpmc the following error comes up:
I probably do not have access to the logs of either domain.
This is working as expected and is not supposed to work. The GPMC console is designed to try to get a operational token for the PDC of the domain environment wherever you are opening the same. Because PDC(primary domain controller role holder in a domain ) is supposed to have the most recent copy of the group policies (but sometimes this is not true due to delayed replication etc.) So when you try to connect to GPMC of another domain it connects and sends a Kereros request which fails to get a ticket(to be considered same as token i mentioned above.) .
If you take a network trace in both the cases you will see that there is a TGT request to get a ticket for SPN ldap/(domain A) from the domain B domain controller which is not possible because you do not have trust between the domains. This fails with "KerberosV5:KRB_ERROR - KDC_ERR_S_PRINCIPAL_UNKNOWN (7)" . This is the moment you see the access is denied error as shown in screenshot . I hope that provides clarity on your query .
It's been a while, but with the help of a colleague we came to a solution. The GPMC has an option called trust detection (View -> Options -> General).
Once this options is disabled, the GPMC has to be closed so that this option is saved. If you then start the GPMC via
runas.exe /netonly /user:<Domain B>\<Domain B User> "mmc gpmc.msc /domain=<Domain B>"
the forest from domain B can be added and you can configure your GPOs as you normally would.
I have a problem with the synchronization of active directory groups with MDM,
The user/password is correct, it is marked so it never expires. Looking at the logs I see the following error:
2016/12/21 07:25:32.433 CSWAIRWZ11 8e66e0df-00a6-4997-a293-bccd713e430c [0000000-0000000] (52) Error WanderingWiFi.AirWatch.BusinessImpl.EnterpriseIntegrationHelper.SearchGroups Directory call failed. System.DirectoryServices.Protocols.LdapException:80090311: LdapErr: DSID-0C0905DE, comment: AcceptSecurityContext error, data 51f, v1db1 Error code:49
Besides the user / password, what other problem could happen?
Thank you very much in advance.
Regards
LDAP Error code 49 means AD_INVALID CREDENTIALS (source).
Are you sure that the AD credentials of the account you are using to bind with your Domain Controller are correct? If yes, then I would try using some alternative bind authentication types supported by AirWatch. In my experience Basic and GSS-Negotiate work the best.
If this still does not work, then install an LDAP client on your console server (like for example LDP.exe) and make sure you can bind with your account.
Hope this helps!
I've been trying to setup SonarQube (v4.1) with the LDAP authentication plugin (v1.4) and I just can't get it to authenticate against my domain user. My config is setup as follows:
#########################
# LDAP configuration
#########################
# General Configuration
sonar.security.realm=LDAP
sonar.security.savePassword=true
sonar.security.updateUserAttributes=true
sonar.authenticator.downcase=true
sonar.authenticator.createUsers=true
ldap.authentication=simple
ldap.realm=mydomain.co.uk
ldap.bindDn=CN=USERNAME,OU=developers,DC=mydomain,DC=co,DC=uk
ldap.bindPassword=PASSWORD
# User Configuration
#ldap.user.baseDn=OU=developers,DC=mydomain,DC=co,DC=uk
ldap.user.request=(&(objectClass=user)(sAMAccountName={login}))
ldap.user.realNameAttribute=cn
ldap.user.emailAttribute=mail
# Group Configuration
ldap.group.baseDn=CN=Domain Users,CN=Users,DC=adastra,DC=co,DC=uk
ldap.group.request=(&(objectClass=group)(member={dn}))
and the log outputs the following messges that seem to say that the LDAP connection is working fine:
2014.01.20 16:12:32 INFO [org.sonar.INFO] Security realm: LDAP
2014.01.20 16:12:32 INFO [o.s.p.l.LdapSettingsManager] Auto discovery mode
2014.01.20 16:12:32 INFO [o.s.p.l.LdapSettingsManager] Detected server: ldap://dc02.mydomain.co.uk:389
2014.01.20 16:12:32 INFO [o.s.p.l.LdapSettingsManager] User mapping: LdapUserMapping{baseDn=dc=mydomain,dc=co,dc=uk, request=(&(objectClass=user)(sAMAccountName={0})), realNameAttribute=cn, emailAttribute=mail}
2014.01.20 16:12:32 INFO [o.s.p.l.LdapSettingsManager] Group mapping: LdapGroupMapping{baseDn=CN=Domain Users,CN=Users,DC=mydomain,DC=co,DC=uk, idAttribute=cn, requiredUserAttributes=[dn], request=(&(objectClass=group)(member={0}))}
2014.01.20 16:12:32 INFO [o.s.p.l.LdapContextFactory] Test LDAP connection on ldap://dc02.mydomain.co.uk:389: OK
2014.01.20 16:12:32 INFO [org.sonar.INFO] Security realm started
But it just doesn't seem to work for my user unless I use a local user. When enabling logging on the wrapper by setting:
wrapper.console.loglevel=DEBUG
I get the following error in the logs which doesn't really help that much! :)
2014.01.20 17:07:10 ERROR [rails] Error from external users provider:
I just worked through getting the SonarQube LDAP plugin to work with Active Directory myself. Since everyone's network is set up differently, you often can't just copy and paste a configuration. Here is the process I used to figure out the correct configuration at my company:
As stated in the documentation, this configuration goes in the file:
SONARQUBE_HOME/conf/sonar.properties
The following line is required as-is:sonar.security.realm=LDAP. Other lines will be different per company.
It was helpful for me to test the configuration with a GUI tool. I used the Softerra LDAP Browser (free read-only version of LDAP Administrator). In that LDAP Browser,
Create a new profile.
Lookup Servers button will help determine ldap.url. You will need to end up with something along the lines of ldap.url=ldap://dc01.mycompany.local:3268. NOTE: As stated in another answer, this may need to be a different port than the one listed in this screen.
The Base DN box can be left blank for now.
For authentication, I just chose the currently logged on user.
The filter can also be left blank for now.
Click Finish and it should display items at the top level of your AD.
F3 toggles the Quick Search bar.
Since you can't connect SonarQube to AD with Anonymous Authentication, you will need to select a user for the SonarQube service to connect as. Search for that user in the Quick Search.
You should find a CN (Common Name) entry. Double-click that to open it up.
Find the distinguishedName field and copy its value to use as your ldap.bindDn
ldap.bindPassword should be that user's password.
That should be enough to let SonarQube start successfully, but it is NOT enough to let it search for the user that is trying to log into your SonarQube web portal. For that, first pick a sample person (such as yourself).
Do another Quick Search for the sample person and open up their CN entry
Take the value of their distinguishedName, remove the "CN={Their Name}," piece, and put that into ldap.user.baseDn
The last piece that you need to determine with the ldap.user.request. The suggestion from the SonarQube docs to use with AD worked for me: (&(objectClass=user)(sAMAccountName={login})). Let me explain why, in case it does not work for you. The "{login}" will be replaced by whatever the SonarQube enters for their username, so that request string (which is called "Filter" in LDAP Browser) is essentially saying to search for all entries with any objectClass equal to "user" and their sAMAccountName equal to whatever is typed into the username textbox in your SonarQube web portal. Inside the sample person's info, there should be at least one field called "objectClass". One of those should have the value "user". There should also be an field for sAMAccountName. Use that value for the username textbox in your SonarQube web portal.
To test if that request string should work for you, do a Directory Search in LDAP Browser (Ctrl+F3). Put your ldap.user.baseDn value in the "Search DN" texbox and put your ldap.user.request value in the Filter texbox (be sure to manually replace "{login}" with your sample username). It should return the CN entry for the sample person.
Thanks to #aaron who managed to point me in the right direction! For my issue it was a problem with the auto-discovery and the forest I was connecting to. According to http://technet.microsoft.com/en-us/library/cc978012.aspx you should use a different port when connecting to a forest so that it can then search the whole forest rather that the domain you happen to connect to (which I suppose might not be the correct one in auto-discovery mode). In the end the configuration that worked for me was:
# General Configuration
ldap.realm=mydomain.com
sonar.security.realm=LDAP
sonar.authenticator.createUsers=true
sonar.security.savePassword=true
sonar.security.updateUserAttributes=true
ldap.url=ldap://dc.mydomain.com:3268
# User Configuration
ldap.user.request=(&(objectClass=user)(sAMAccountName={login}))
ldap.user.realNameAttribute=cn
ldap.user.emailAttribute=mail
Which is actually quite simple and doesn't require a user account to connect with. This means it is in SIMPLE authentication mode (I can't seem to get it to work in anything else) but that is fine with me as it's an internal only system.
I am using SonarQube 3.7.3 and I attached my configuration which works. I hope that would be useful.
# General Configuration
sonar.security.realm=LDAP
sonar.authenticator.createUsers=true
sonar.security.savePassword=true
sonar.security.updateUserAttributes=true
ldap.url=ldap://...
ldap.bindDn=user
ldap.bindPassword=password
# User Configuration
ldap.user.baseDn=ou=People,dc=company,dc=local
ldap.user.request=(&(objectClass=user)(sAMAccountName={login}))
ldap.user.realNameAttribute=cn
ldap.user.emailAttribute=mail
My Fix
I had painstakingly verified my settings, even to the point of using the log file's "User mapping" output line to configure a manual ldapsearch command and verify that my user was being retrieved properly.
For some reason, specifying this setting fixed it for me:
ldap.user.realNameAttribute=cn
Why?
This attribute is supposed to be optional and default to cn anyway, but it only works for me if I specify it manually. This might be a bug.
Debugging with ldapsearch
ldapsearch can allow you to bypass the application query LDAP directly.
I looked in the log file for this line:
INFO web[o.s.p.l.LdapSettingsManager] User mapping: LdapUserMapping{baseDn=DC=my-ad,DC=example,DC=com, request=(&(objectClass=user)(sAMAccountName={0})), realNameAttribute=cn, emailAttribute=mail}
And then built an ldapsearch command like:
ldapsearch -D CN=myldapuser,CN=Users,DC=my-ad,DC=example,DC=com -W -h my-ad.example.com -b "DC=my-ad,DC=example,DC=com" "(&(objectClass=user)(sAMAccountName=myuser))"
-D specifies the bind DN, basically the login username for LDAP
-W means that ldapsearch will prompt you for the password
-h specifies the LDAP URL
-b should be baseDN from the log file line
The last positional parameter is the request value from the log file line, after replacing {0} with a real username.
If you get real user info back, it means your basic settings are right. This is a hint that something else is going wrong.
http://blogs.msdn.com/b/visualstudioalm/archive/2015/11/13/support-for-active-directory-and-single-sign-on-sso-in-the-sonarqube-ldap-plugin.aspx
With the new v1.5, only one line is required:
LDAP configuration
sonar.security.realm=LDAP
Using port 3268 did the trick for me. Here is my configuration that works with SonarQube 5.0.1 and Active Directory:
sonar.security.realm=LDAP
sonar.security.savePassword=true
sonar.security.updateUserAttributes=true
sonar.authenticator.createUsers=true
ldap.url=ldap://dc101.office.company.com:3268
ldap.bindDn=CN=Service Account,OU=Windows Service,OU=Accounts,OU=Resources,DC=office,DC=company,DC=com
ldap.bindPassword=PASSWORD
ldap.user.baseDn=DC=office,DC=company,DC=com
ldap.user.request=(&(objectClass=user)(sAMAccountName={login}))
ldap.user.realNameAttribute=cn
ldap.user.emailAttribute=mail
None of solutions before worked for me, but this:
# Configuration
sonar.realm=myreal.domain.com
sonar.security.realm=LDAP
sonar.authenticator.createUsers=true
sonar.security.savePassword=true
sonar.security.updateUserAttributes=true
ldap.url=ldap://myreal.domain.com:389
ldap.bindDn=cn=CNUser,dc=domain,dc=com
ldap.bindPassword=password
# User Configuration
ldap.user.baseDn=ou=people,dc=domain,dc=com
ldap.user.request=(&(objectClass=user)(sAMAccountName={login}))
ldap.user.realNameAttribute=cn
ldap.user.emailAttribute=mail
#logeo lo que pasa
wrapper.console.loglevel=DEBUG
My Ldap server do needs authentication, so i cant avoid that. If it doesnt works for you, try not to especify the ldap.user.request: all depends of the configuration of your network´s LDAP server.
We have a Plone 4.3 site on debian 7 that we'd like to authenticate against an existing AD controller. Using the excellent plone.app.ldap product we have this working, but the 'manager' username/password are being sent over the wire in plain text.
No doubt this is because we are using the protocol: 'LDAP' and not 'LDAP over SSL', our problem is how to implement 'LDAP over SSL' on the AD server in a way that works with Plone. Has anyone had any experience configuring the AD machine to accept these types of requests?
From what I understand it needs to be a new service on a new port, similar to https (i.e. not TLS), but I don't know enough about AD to know what to ask the AD admin mob.
EDIT: following the comment from #Martijn Pieters I add that if we set the 'manager dn usage' to not always then we get this error in the event log:
OPERATIONS_ERROR: {'info': '000004DC: LdapErr: DSID-0C0906E8, comment: In order to perform this operation a successful bind must be completed on the connection., data 0, v1db1', 'desc': 'Operations error'}
Thanks for any ideas.
-i
You could set up the LDAP connection to use a certificate instead of a password.
Ross Patterson outlines the procedure, but the mailinglist post he links to is gone. The same thread is however still available on GMane.