You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
I am open to the possibility that it may just be a lingo difference, as I know Crowd can do SSL and can use a dedicated AD account to connect to LDAP.
Microsoft is implementing a LDAP channel binding and LDAP signing, and I have not find any Atlassian / Crowd documentation on this, just LDAP SSL and connection howtos/troubleshooting.
To make sure, is Crowd compatible? Which settings is required and reference to for Crowd connecting to LDAP?
How did you go with that?
We've implemented LDAP over TLS, but still seeing unsigned binds
Log Name: Directory Service
Event ID: 2889
Task Category: LDAP Interface
User: ANONYMOUS LOGON
The following client performed a SASL (Negotiate/Kerberos/NTLM/Digest) LDAP bind without requesting signing (integrity verification), or performed a simple bind over a clear text (non-SSL/TLS-encrypted) LDAP connection.
Client IP address:
Identity the client attempted to authenticate as:
No, as it was a response from Atlassian Support.
"Good day Melanie,
Thanks for your patience.
We reviewed Microsoft's documentation regarding the upcoming changes and confirmed it's just about enforcing secure connections (LDAPS) and other internal changes in the Windows registry (these settings already exist, but they are disabled by default).
We do not foresee any impact in the way Atlassian applications connect to Active Directory, and the settings can be disabled if there's any incompatibility. "
Yes, we would like an idea on where Crowd is with this.
Hi @Melanie Pasztor ,
Crowd is compatible with LDAP and you can use the option of LDAP directory connector instead of a delegated authentication
With delegated authentication, users are only retrieved in Crowd after they successfully authenticate.
You don't need to have any write privilege on AD for standard LDAP directory connector. The connector will synchronize users and groups from AD into Crowd and won't do any write operations on AD, at least if you don't want to. You should configure the connector with an AD user that does not have any write privileges on AD.
For more info, refer to this community thread
Thank you for the answer. It is not the question though, as I am wondering if that is compatible with Microsoft LDAP update that is coming up. LDAP channel binding and LDAP signing.
At present, we already are using read-only LDAP connector. Now we want to make sure it is secure and will not stop working after the Microsoft update in January 2020. If it will, we would like to correct that before then.