Hello,
I configured a Authentications Source with LDAP (simple auth). It works, but I only can login with the Display Name. It is nessesary to login with the sAMAccountName. Does anyone have an idea how I can configure to login with sAMAccountName?
Thanks!
Hi,
whats your current auth source configuration - maybe i can help.
BTW im using “sAMAccountName” for login not display name.
Regards
try using only:
User Filter = (sAMAccountName=%s)
Username Attribute = sAMAccountName
That works for me
Thank’s I have tried this but it doesn’t work for me…
It only works if the DisplayName and the sAMAccountName are the same.
I think it’s because in User DN there is cn=%s but I don’t see any other possibilities to make it different.
Does anyone have another idea how to fix that?
Solved:
I have created the Aut. via BindDN, now it works.
Hi @mob1907,
I’m also trying to use sAMAccountName for LDAP login. I’m trying to use it with simple auth. I put the configuration in the settings and I try it with AdFind to check the LDAP query.
My User Filter also checks if the user is in a group, but I also have “sAMAccountName=%s”. I also write User DN and check it with AdFind.
With AdFind, I think that User DN is “-b” flag & User Filter is “-f” flag.
Do you know if I’m missing something?
Here you have a screenshot
Well, hi, there! 
I use an MSI tool named ADSI Edit (in the server, open mmc console, add/remove snap-in, add ADSI Edit) to check the actual distinguished name (path) for the users in the active directory. You need to check the default naming context for your server (it should be the first branch in your tree).
In my case, which is simpler than yours, I have CN=Users(1), DC=xxx(2), DC=yyy(3), DC=zzz(4) in that order. If you have organization units defined, a PATH for that must also exist (otherwise your configuration is wrong).
If your query already matches the exact path constructed from the tree (a tree branch that combined exactly reproduces your query, including your OU, etc.), then we have a problem. But I guess (sorry to assume) you are adapting your query from the examples and missing some detail in the exact path required for the query.
Nevertheless, in ADSI Edit you can right-click in the default naming context and “New Query” and see what and where the users are found:
If that doesn’t work for you, I suggest you try to use the most basic configuration, which is CN=Users,DC=yourdomain,DC=country (adapt this according to what you see in ADSI edit). Once you have that working, you can build up from there and see how to filter by OU, but at least you’ll have a starting point.
Hi @guillep2k,
I check our Active Directory and in our case, all users are at “CN=Usuarios,DC=domain,DC=local”. It’s in Spanish, but it should work exactly as in English.
I also tried to filter using AdFind and it works:
AdFind -b dc=<domain>dc=<local> -f "(&(memberOf=cn=<group>,ou=Usuarios,dc=<domain>,dc=<local>)(sAMAccountName=<%s username>)(!(UserAccountControl:1.2.840.113556.1.4.803:=2)))"
I don’t think I’m missing something. Is it possible to change the verbosity of logs in a Docker, or do I need to restart the service?
Thank you so much for your time,
There’s something wrong here. You say that all users are at CN=Usuarios … but then you query is under OU=Usuarios. Which is it? OU? CN? It should be CN.
Also, AdFind should brinng a zero result if you check <%s username>.
Anyway, try removing the &(memberOf=cn=<group>,ou=Usuarios,dc=<domain>,dc=<local>) part and check with that. We may have some progress if we simplify the test. My most successful strategy for addressing problems with computers: “divide y vencerás”. 
In fact, shouldn’t it be: ?
V V
AdFind -b dc=<domain>dc=<local> -f "(&(memberOf=ou=<group>,cn=Usuarios,dc=<domain>,dc=<local>)(sAMAccountName=<%s username>)(!(UserAccountControl:1.2.840.113556.1.4.803:=2)))"
Yes, it is. But I put the “<>” and the message remove them. Maybe it is a special character here.
I tried to use AdFind with this command and it works:
AdFind -b dc=<domain>,dc=<local> -f "(&(sAMAccountName=<%s username>)(!(UserAccountControl:1.2.840.113556.1.4.803:=2)))"
For the filter I use the same that returns me AdFind when I get the field memberOf of my user. This field says that Usuarios is a OU.
@guillep2k I also realized that my DN has the following format:
CN=<my_display_fullname>,OU=Usuarios,OU=<department>,OU=<office>,DC=<domain>,DC=<local>
In my case, the users will have the same department . But the office is different (Barcelona, Madrid, London…).
The group has the same format, but department and office is always the same for everyone.
Maybe our AD is misconfigured? Or will it be a problem to use LDAP with different OU?
Thank you so much for your time,
You can imagine the search path (“Base de búsqueda de usuarios”) as a file directory spelled backwards and the leaf (the first component) as a regular file. For example, if your user mike@monstersinc.com is at:
CN=Mike Wasowsky,OU=Usuarios,OU=Monster Assistance,OU=Energy,DC=monstersinc,DC=com
Then you can find the leaf (CN=Mike Wasowsky) by searching in any of these paths:
OU=Usuarios,OU=Monster Assistance,OU=Energy,DC=monstersinc,DC=com
OU=Monster Assistance,OU=Energy,DC=monstersinc,DC=com
OU=Energy,DC=monstersinc,DC=com
DC=monstersinc,DC=com (that's as far as it will go, since this is the route)
Searches in any of those paths will find the user whose sAMAccountName is mike. You need to leave out the first element (CN=Mike Wasowsky) as it is your user, and no leaf will be find below it with sAMAccountName = mike
The shorter the path specification, the longer the search will take (and it will perhaps bring up nodes that you don’t want to find).
Finally:
(&(memberOf=cn=<group>,ou=Usuarios,dc=<domain>,dc=<local>)(sAMAccountName=<%s username>)(!(UserAccountControl:1.2.840.113556.1.4.803:=2)))
Is the condition your leaf must pass in order to be found. Perhaps the whole memberOf=... is not needed since you can provide the path in the search path (“DN de usuario”).
Lastly, “DN de usuario” is your LDAP account to validate the user:
CN=administrador,DC=monstersinc,DC=com
Here’s a guide (in French) that you can pass through Google Translate and have a pretty good idea of how to configure this.
EDIT: I mixed up the field names; corrected.
Thank you so much @guillep2k
In my case, I’ll need to have the “Base de búsqueda de usuarios” with only the DC, because the first UO changes. And I’ll try to put the DN of the group in “DN de Usuario”
“Base de Búsqueda de usuarios” (User Search Base)
dc=<domain><dc=local>
“DN de Usuario” (User DN)
ou=<group>,ou=Usuarios,ou=<dept>,ou=<office>,dc=<domain>,dc=<local>
“Filtro de Usuario” (User Filter)
(&(objectCategory=Person)(sAMAccountName=%s))
There are lots of answers with BindDN. I’ll need an Active Directory admin account to use BindDN… It’s strange that I need to use this account to the users.
I’ll write as soon as I can test it.
Edit: I thought that the integration would be easy because I developed a service that uses NPM activedirectory package: https://www.npmjs.com/package/activedirectory
Thank you so much,
Hi again @guillep2k
I’m using now BindDN and everything is working perfectly. It’s strange that BindDN is required for this.
Thank you so much,