Ldaprecord-laravel: [Question] ActiveDirectory vs LDAP

[realtebo]

Hi ! Sorry for opening a blank issue, but we're in a field where we never entered before.

A big company uses AD with LDAP (I don't event know what damn it means) and we're required to create our new webapp using users from AD/LDAP.

I ask you kindly if authenticating users when using AD is a different from when using LDAP.

I ask you because I created an OpenLDAP server on Debian to try the login and I noticed in this server i cannot login using classical DOMAIN\username as username

Is your package able to handle AD ?

Thanks

PS: how do we can became sponsor?

[stevebauman]

Hi @realtebo! No problem opening an issue, I'm always happy to help ❤️

I ask you kindly if authenticating users when using AD is a different from when using LDAP.

Nope! AD is accessed using the LDAP protocol. LdapRecord is actually suited best for ActiveDirectory 👍

I ask you because I created an OpenLDAP server on Debian to try the login and I noticed in this server i cannot login using classical DOMAIN\username as username

Unfortunately OpenLDAP does not support logging in users by that format (DOMAIN\username) as you've discovered. Only Active Directory supports this username format. I've actually written about that here if you'd like to know more about the formats of LDAP authentication:

https://ldaprecord.com/docs/core/v2/configuration/#username-amp-password

Is your package able to handle AD ?

Yup! It certainly is.

PS: how do we can became sponsor?

If you'd like to sponsor (entirely optional), you can visit this page:

https://github.com/sponsors/stevebauman

Let me know if you have any further questions and I'd be happy to answer them 😄

[realtebo]

About these config:

LDAP_USERNAME="cn=user,dc=local,dc=com"
LDAP_PASSWORD=secret

What is this specific user?

I need to log into our app using any users on Active Directory.
What is the goal of this ?
If this is not needed, how to 'reset' it? simply set to null?

[stevebauman]

About these config:
What is this specific user?

You must configure a username and password so LdapRecord has the ability to search your directory for the user logging into your application to retrieve their account details. This is similar to how you must configure a username and password to connect to your applications database to retrieve data inside.

If your Active Directory server supports anonymous binding, then you can set both LDAP_USERNAME and LDAP_PASSWORD to null:

LDAP_USERNAME=null
LDAP_PASSWORD=null

[realtebo]

Main question: to do ONLY LOGIN, do we need this user?

[stevebauman]

Main question: to do ONLY LOGIN, do we need this user?

Yes. This allows you to be able to sign in LDAP users into your application with any attribute you like. This grants LdapRecord some major advantages, since the same configuration parameters can be utilized with any LDAP server, regardless of what username formats it supports.

This is very common practice. Printers, telephones, and other hardware that integrates with LDAP require you to configure a username and password to authenticate and retrieve details from the LDAP server.

[realtebo]

So to allow users to login we need another user, a different one, to be used as technical bridge to AD.

This user logs into AD silently via your package, and allow other users to login ?

I try to configure on our AD test server a new user able to list. I am Googling to find exact config needed

[realtebo]

I can confirm your suggestions are all goods and working.

• Added a new user to be used only from app internally
• The domain's has been modified in the security to allow 'read' from this new user
• Added the needed .env configurations;

LDAP_BASE_DN="OU=Utenti Interni,OU=Utenti,OU=DFS Test,DC=dfsdomtest,DC=local"
LDAP_USERNAME="CN=App,OU=Utenti Interni,OU=Utenti,OU=DFS Test,DC=dfsdomtest,DC=local"
LDAP_PASSWORD="Password123!"

[stevebauman]

Glad you were able to get it working @realtebo!

This user logs into AD silently via your package, and allow other users to login ?

Basically. It simply allows LdapRecord to find a user in your domain by the attribute you want to authenticate them by. For example, the mail, samaccountname, userprincipalname etc.

Then, when it finds a user, it will pull their distinguished name and attempt to bind that user with their full DN and the password they submitted in the login form.

This is what allows us to work around the requirement of having users enter their full distinguished name to be able to bind to an LDAP server.