I've got an instance of sonarqube 5.5 running.
I wanted to use the sonar-ldap-plugin 1.5.1 in order to delegate the authentication and authorization to the Active Directory service of my company.
The configuration for the LDAP plugin is the following (modulo some obfuscation):
sonar.authenticator.createUsers=false
sonar.security.savePassword=false
sonar.security.realm=LDAP
ldap.url=ldap://host.my.domain
ldap.user.baseDn=OU=Users,OU=Organic Units,DC=my,DC=domain
ldap.user.request=(&(objectClass=user) (sAMAccountName={login}))
ldap.authentication=DIGEST-MD5
ldap.bindDn=CN=harmlessServiceAccount,OU=users,OU=Organic Units,DC=my,DC=domain
ldap.bindPassword=<the user password in clear text>
sonar.log.level=DEBUG
And the sonarqube server reports the following error:
2016.07.13 10:19:38 INFO web[o.s.p.l.LdapContextFactory] Test LDAP connection: FAIL
2016.07.13 10:19:38 ERROR web[o.a.c.c.C.[.[.[/]] Exception sending context initialized event to listener instance of class org.sonar.server.platform.PlatformServletContextListener
java.lang.IllegalStateException: Unable to open LDAP connection
...
Caused by: javax.naming.AuthenticationException: [LDAP: error code 49 - 8009030C: LdapErr: DSID-0C0904DC, comment: AcceptSecurityContext error, data 52e, v1db1^#]
...
I did the exact same query with ldapsearch and did not meet any problem. So I think the Active Directory service is correct and accepts this user and the DIGEST-MD5 SASL mechanism.
I also used the same user through sonarqube with the SIMPLE (unsecure) mechanism and it was working "properly" as well.
I also tried to put the md5 hash of the password instead of the password.
And I tried a lot of other things I'm not proud of...
I read many similar issues online (stack overflow, other sources) and couldn't find a solution yet.
Do you see anything wrong in my configuration?
Am I doomed to use the SIMPLE mechanism and let everyone's password move around in clear text?
I cannot use CRAM-MD5 neither GSSAPI as they are not supported by my company's active directory service.
The error code 49, has a subcode in it that tells you what the failure cause was. You reported:
[LDAP: error code 49 - 8009030C: LdapErr: DSID-0C0904DC, comment: AcceptSecurityContext error, data 52e, v1db1^#]
The data 52e part is the key.
Check out the list I maintain here, and you will see that 52e means bad password for your bind user. 525 would be bad DN for your user, so you have the correct LDAP DN, but the wrong password.
I just encountered this and fixed it on sonarqube 6.x. and ldap plugin 2.2
The 52e will be a bit misleading I found as it can be invalid password, but that is also possible if the login is incorrect. http://ldapwiki.com/wiki/Common%20Active%20Directory%20Bind%20Errors
I had the following in my config
ldap.bindDn=domain\query_account
This has worked for other things but not SonarQube. Your line sonar.log.level=DEBUG actually helped me, I turned it on and it showed me the problem, I needed to escape the \ character. So this worked for me.
ldap.bindDn=domain\\query_account
this might not be your problem, but it definitely was mine. Hope it helps.
Related
I have a school projet that require me to emulate the CVE-2020-1472 (Zerologon) on a local environment.
I am currently trying to test following github script but I am facing some issue that I haven't been able to solve since then.
To sumerize, I have a :
Ubuntu 16.04 machine with Samba 4.3.8 Domain Controller Active Directory
Windows Server 2019 that joined the domain EXAMPLE.COM that I created with Samba.
I've made several test and I can succesfully modify the password of the "Administrator" account with first part of the POC :
./cve-2020-1472-exploit.py -n EXAMPLE-DC -t 1.2.3.4
Problem comes when trying to run impacket to extract some data from the domain :
secretsdump.py -no-pass -just-dc Domain/'DC_NETBIOS_NAME$'#DC_IP_ADDR
It sucesfully log in but then I get this message :
Password:
[*] Dumping Domain Credentials (domain\uid:rid:lmhash:nthash)
[*] Using the DRSUAPI method to get NTDS.DIT secrets
[-] DRSR SessionError: code: 0x20e4 - ERROR_DS_CANT_FIND_EXPECTED_NC - The naming context could not be found.
[*] Something wen't wrong with the DRSUAPI approach. Try again with -use-vss parameter
[*] Cleaning up...
UPDATE 1 :
I also tried to use the -use-vss option but it also fails after login in.
[-] RemoteOperations failed: DCERPC Runtime Error: code: 0x5 - rpc_s_access_denied
[*] Searching for NTDS.dit
[-] 'NoneType' object has no attribute 'request'
[*] Cleaning up...
I tried to get some information about the DRSR SessionError: code: 0x20e4 - ERROR_DS_CANT_FIND_EXPECTED_NC but I didn't found any usefull informations on internet..
I hope someone have already faced this error or have knowledge regarding Active Directory because I'm really stuck
Thanks in advance and have a good week !
UPDATE 2:
I made a post on impacket's github and it seems like the DRSUAPI approach hasn't been tested against a non Windows AD before. So secretsdump wont works.
Every page mentioned SAMBA as vulnerable so I wonder if they really tested to exploit the vulnerability or if it was just a theoretical assumption.
I'm trying to connect to an SFTP server for which I have passwordless authentication setup. I can connect to this server from the terminal. However, when I try to access the server using Springboot - Camel-SFTP, I get an exception:
2018-08-29 14:59:24,617 WARN org.apache.camel.component.file.remote.SftpConsumer : Error auto creating directory: incoming due Cannot connect to sftp://username#host.net:22. This exception is ignored.
org.apache.camel.component.file.GenericFileOperationFailedException: Cannot connect to sftp://username#host.net:22
Caused by: com.jcraft.jsch.JSchException: Auth fail
at com.jcraft.jsch.Session.connect(Session.java:519)
at org.apache.camel.component.file.remote.SftpOperations.connect(SftpOperations.java:116)
... 33 common frames omitted
This is the endpoint for my route:
file-endpoint: sftp://username#host.net/incoming?streamDownload=true&noop=true&disconnect=true&stepwise=false&useList=false&fileName=abc.txt&ignoreFileNotFoundOrPermissionError=false&sendEmptyMessageWhenIdle=true&privateKeyPassphrase=XXX&preferredAuthentications=publickey&privateKeyFile=/Users/username/.ssh/id_rsa&scheduler=spring&scheduler.cron=0+0/1++++
Any help would be appreciated. Thanks!
From the filename, I'd assume an RSA key -- be sure that this is the case. I've had problems with JSch using an ed25519 key.
Additionally, in the SFPT route's that I've set up, I don't use "user#" in the URI; I just have
sftp://some.host/directory?username=someone?privateKeyFile=<>[..options..]
but I don't include a blank password attribute as indicated by fliot
Finally, you might try to check the destination server's sshd log; it may have something useful.
Simple answer : Add username and password, even if password may be empty.
Long answer:
I got several working routes with
username=something&password=&privateKeyPassphrase=XXX&preferredAuthentications=publickey&privateKeyFile=id_rsa
By the way, the path of your private key, make me anxious, by default, on linux, a local user is allowed to use local file as private ssh key, only the key is "chmod 400", or similar. Please, check your Karaf or Servicemix instance can correctly read this path.
Additionnaly, you can see the entire sFTP workout, with
log4j.logger.org.apache.camel.component.file.remote.SftpOperations = ON
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!
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.
I have set the ActiveDirectoryMembershipProvider connectionProtection attribute to secure, according to MSDN documentation states that when this is set to secure the following holds:
"The ActiveDirectoryMembershipProvider class will attempt to connect to Active Directory using SSL. If SSL fails, a second attempt to connect to Active Directory using sign-and-seal will be made. If both attempts fail, the ActiveDirectoryMembershipProvider instance will throw a ProviderException exception."
The code works and queries can be made against the LDAP but one issue that has me a little confused is that my connection string is prefixed with LDAP and not LDAPS. Changing this to LDAPS results in the following error:
"Parser Error Message: Error HRESULT E_FAIL has been returned from a call to a COM component."
What is happening here? In the first instance where the connection string is simply LDAP is SSL being used? The documentation indicates that if it is not, an exception should be thrown. If not, then what would be the likely cause for this error in this context?
As far as I know, all the LDAP DN's (distinguished names) always have an LDAP only prefix - whether they're over a secure link or not. The secure aspect typically shows up by means of the port on the server being used, 389 being the default for non-secure, and 636 being the default for a secure communication.
But the spec of the LDAP distinguished names doesn't have a LDAPS prefix, really. I've done a lot of LDAP work a few years ago, and I do remember having to deal with different ports for trusted or secured communications, but I never once had a full-qualified LDAP path have anything else but an LDAP:// prefix (case sensitive, too!).
The LDAP:// prefix is used both for clear and SSL connections, to check whether the communication is indeed under SSL try step 3 of this blog entry http://erlend.oftedal.no/blog/?blogid=7