ahaenggli/AzureAD-LDAP-wrapper

AzureAD-LDAP-wrapper forwarding queries to Azure ?

marc-odp opened this issue · 7 comments

From the doc :

As domain and basedn it is recommended to use the same as used in AzureAD tenant (e.g. @domain.tld). This way, the spelling of the users (e.g. username@domain.tld) will match at the end. Otherwise, your users will have to use username@example.com instead of the estimated username@domain.tld, for example.

Reading this description, I was under the impression that I had to specify the exact same domain name that I registered in azure.
However, I discovered that when the client computer contact the AzureAD-LDAP-wrapper local server, the server is in fact not authenticating but forwarding the query to azure...
Did I misunderstood the system ? I was thinking that AzureAD-LDAP-wrapper was independent.
I found this because some of my users could authenticate on my local computers and others not. (Those who never used their login in Azure/Teams were unable to login locally).

AzureAD-LDAP-wrapper log
image
Azure log
image

Since, each 30 minutes the local LDAP is retrieving the list of users from Azure, why is it needed to contact Azure each time a user wants to login ? What is happening when there is no internet ? Is the local LDAP doing the authentication ?

This LDAP server is not independent. It is only a wrapper.
Every 30 minutes, the list of users and groups is retrieved. This way, permissions can be defined on the NAS and the LDAP server can answer basic queries. The password of the users cannot be retrieved by the Graph Api. Therefore, the users' credentials are forwarded to Azure. In case of a successful login, a password hash is cached (if not configured otherwise). Depending on the login error (e.g. no internet, name resolution, ...), the user password is compared with the hash in the cache to allow a login anyway.

Thank you for these explanations. That explains many things.
In our case, we could not have a successful login because the users had their password reset in Azure by an admin. In case of a new user or a user who got his password reset, the wrapper cannot be used, even if the login and password are good.

I don't quite understand. Why can't the wrapper be used with a new user or a reset password? Do you have a setting that the user must change the password as the first action? If so, the user needs to change the password in Azure first, then it should work again... A failed login is also logged in the wrapper, with the associated Azure error message. Can you possibly get more details about the behavior from there?

I didn't select the option "user must change...", so this is not the problem.
For the new user. I think that it is maybe the missing recovery settings : when a user log in to office365 for the first time he has to select a way to recover his account by providing a phone number or another email account. Maybe AzureAD-LDAP-wrapper login failed because it was not done.
For the reset of password, I don't know. I didn't test deeper enough.

AzureAD-LDAP-wrapper

image

Office365 (After the access panel is done, log in is ok)

image

I think this is the problem : "Require users to register when signing in"

image

Azure decides in each case whether a login was successful or not. The behavior of the wrapper is correct...
With the next version, a different library will be used for the login, possibly more details will be returned there in such constellations. If not, you would have to look in the Azure access log to see if more details can be found there.