Using Gluu as LDAP (AD) interface

By: Mahendran Mookkiah Account Admin 15 Sep 2020 at 9:14 p.m. CDT

7 Responses
Mahendran Mookkiah gravatar
## Background We have a third party application (say A) which does only support Active Directory (AD) integration for authentication. So far we used our corporate AD and all our employee can login. With Gluu's introduction, we are creating non employee (external) as user in Gluu which end up in OpenDJ. We want these external users to have access to application A. In Gluu we are using cache refresh to get employee accounts to be available in OpenDJ. I believe it is not mirroring the password field from AD to OpenDJ. I think that is expected. As openDJ is LDAPv3 complaint, we can integrate the application A to delegate the authentication to OpenDJ. Here comes the challenge. * When application A uses OpenDJ, it can authenticate external users. But failed to authenticate employee credential as it does not have. * When application A uses AD, it can authenticate employee but not external as the external users only in Gluu OpenDJ. ## Question 1 Is there an abstract LDAP interface offered by Gluu which we can be configured with application A? When the user authenticates, it can check the credential as configured in "Managed Authentication". In our case check first in OpenDJ then check with AD. Benefits: 1. AD is not required to populated with external user account for the sake of getting one application access. 2. AD is not going to be exposed to 100s of application with service accounts. ## Question 2 Is it possible to cache the userPassword (one way hashed) and the hashing algorithm used in AD? so that Gluu can validate the user password without reaching out AD whenever user enters credential. Risk : When user changed the password in AD, Gluu will allow old password until cache refresh is done. Benefit: User can login even AD is down. AD is not going to get hit on every user login.
Docker 19.03
closed

Answers

By Mohib Zico staff 15 Sep 2020 at 10:32 p.m. CDT

Copy
Mohib Zico gravatar
Hi Mahendran, We have organizations ( specially EDU ) who has legacy AD already there. User's passwords are stored in AD ( Gluu Server only caching user's information [ i.e. required attributes ] in OpenDJ ), they are 'validating' user's password against AD without any issue. So, you shouldn't have any problem in 'Question 1' scenario. >> so that Gluu can validate the user password without reaching out AD whenever user enters credential. How do you think Gluu can 'validate' password? Against what?

By Mahendran Mookkiah Account Admin 16 Sep 2020 at 6:11 a.m. CDT

Copy
Mahendran Mookkiah gravatar
In our cache refresh we are using copy refresh method and having the mapping as follows... ``` sAMAccountName=uid givenName=givenName sn=sn mail=mail sAMAccountName=preferredUsername cn=displayName ``` In the Configuration -> Manage Authentication -> Manage LDAP Authentication, it is configured with opendj follwed by company AD. With this configuration, Here is **my understanding how an employee credential gets validated** When employee enters their correct AD username and password in Gluu login page --> Gluu validates the credential against openDJ. (In our case Gluu does not have the password as it is not mapped) so it will fail. --> Then Gluu will delegate the authencation to company AD by passing the credential. It will pass. As you have mentioned " Gluu can validate the user password without reaching out AD", I believe we are missing to copy the userPassword from AD to Gluu during cache refresh. Correct me if I misunderstood. We will try mapping userPassword and see if I can login without AD communication (I will try blocking Gluu to AD either at kubernetes network policy level or changing connection details at Manage LDAP Authentication.

By Mohib Zico staff 16 Sep 2020 at 6:22 a.m. CDT

Copy
Mohib Zico gravatar
>> When employee enters their correct AD username and password in Gluu login page --> Gluu validates the credential against openDJ. Shouldn't that be same as Gluu is reading password _from_ OpenDJ and trying to validate _with_ same password string? >> As you have mentioned " Gluu can validate the user password without reaching out AD", I believe we are missing to copy the userPassword from AD to Gluu during cache refresh. Correct me if I misunderstood. Sorry, I said : "*they are 'validating' user's password against AD without any issue.*". No, they are not storing password in OpenDJ ( which is inside their Gluu Server ). When user authenticate ( put login password in oxAuth login page ), the 'Manage Authentication' is forwarding the checkup to AD for validation. After validation, they get "good" / "bad" signal and Gluu Server work accordingly.

By Michael Schwartz Account Admin 16 Sep 2020 at 2:46 p.m. CDT

Copy
Michael Schwartz gravatar
A few things to keep in mind: 1. AD uses a proprietary hashing algorithm. Thus we cannot sync passwords from AD to OpenDJ, because OpenDJ would not be able to validate them. This is why we recommend sending the BIND request to AD for validation. 2. It depends how end users update their password. If they use a web page, you can write the password to both OpenDJ and AD. In this case, you could certainly implement an authentication workflow that checks two servers. See an example of this [here](https://github.com/GluuFederation/oxAuth/tree/master/Server/integrations/basic.multi_auth_conf). And other workflows can be implemented, as long as you can show a sequence diagram or flow chart of what you expect. 3. If end users use CTL-ALT-DEL to update their windows password, you may need some kind of windows server plugin to catch the password before it's hashed, and propagate it to OpenDJ. Gluu does not offer this kind of product, but there are certainly third party vendors who specialize in password management.

By Mahendran Mookkiah Account Admin 18 Sep 2020 at 10:53 a.m. CDT

Copy
Mahendran Mookkiah gravatar
Hi @Michael.Schwartz, Thanks for opening different option for me to think outside of the box. Based on the point 1, I dropped the possibility of mapping userPassword moreover I dont see it visible to map. Point 3 is good to know, it may open up large discussion and we will not go that route unless it is necessary. Point 2 allows custom authentication flows. It is not going to meet the need as Gluu is not abstracting this script by exposing an LDAP port for the application A to integrate. Does gluu has LDAP Complaint endpoint which can go through custom script?

By Michael Schwartz Account Admin 18 Sep 2020 at 2:51 p.m. CDT

Copy
Michael Schwartz gravatar
We don't recommend exposing the Gluu LDAP server to other applications. It would be better to sync Gluu with an external LDAP server to which applications can access. There are a few reasons for this: 1. You'd have to put the Gluu LDAP server on a network facing interface 2. You'd have to add credentials and ACI's for any external applications 3. Any third party applications would break if we change the DIT or schema--and there is no guarantee we won't do this. 4. It opens a security can of worms--once other applications can access this database, it raises questions about data integrity.

By Mahendran Mookkiah Account Admin 18 Sep 2020 at 3:34 p.m. CDT

Copy
Mahendran Mookkiah gravatar
Thanks for recommendation. Your comments is helping us to take decision quickly. I appreciate the prompt response. Closing this ticket.

Post an answer