mail as user identifier leads to php error

[microbearlogist]

Hello,

In actual v1.10. Setting the LDAP_ACCOUNT_ATTRIBUTE to "mail", leads to the following php error: (default "uid" account attribute works well)

Warning: Cannot modify header information - headers already sent by (output started at /opt/ldap_user_manager/includes/ldap_functions.inc.php:126) in /opt/ldap_user_manager/log_in/index.php on line 43

[wheelybird]

The LDAP lookup probably threw an error. Are you able to include some logs with LDAP_DEBUG=true?

[microbearlogist]

LDAP lookup seems fine, but I may have missed something:

The associated LDAP_Debug:

[client x.x.x.x:y] Running LDAP search for: mail=mail@exemple.com, referer: https://auth.com/log_in/ [client x.x.x.x:y] LDAP search returned 1 records for mail=mail@exemple.com, referer: https://auth.com/log_in/ [client x.x.x.x:y] Entry 1: uid=user-exemple,ou=people,dc=organization,dc=com, referer: https://auth.com/log_in/ [client x.x.x.x:y] Attempting authenticate as mail@exemple.com by binding with uid=user-exemple,ou=people,dc=organization,dc=com , referer: https://auth.com/log_in/ [client x.x.x.x:y] Failed to start STARTTLS connection to ldap://openldap: Connect error, referer: https://auth.com/log_in/ [client x.x.x.x:y] Able to bind as mail@exemple.com, referer: https://auth.com/log_in/ [client x.x.x.x:y] LDAP RFC2307BIS detection - found that the 'subschemaSubentry' base DN is 'cn=Subschema', referer: https://auth.com/log_in/ [client x.x.x.x:y] LDAP RFC2307BIS detection - found 104 objectClasses under cn=Subschema, referer: https://auth.com/log_in/ [client x.x.x.x:y] LDAP RFC2307BIS detection - found AUXILIARY in posixGroup definition which suggests we're using the RFC2307BIS schema, referer: https://auth.com/log_in/ auth.com:80 x.x.x.x - - [07/Jul/2023:16:43:02 +0200] "POST /log_in/ HTTP/1.1" 200 468 "https://auth.com/log_in/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/115.0"

[wheelybird]

Yeah, that looks okay. I'll need to try this locally.

[wheelybird]

Right. The upshot is that we expect LDAP_ACCOUNT_ATTRIBUTE to be part of the account's DN. The code tries to extract the value of the account attribute in order to create a session file. However the authentication has worked as expected - this is just a bug in the code. I think if we get the entire DN and use that for the session name then there should be no issue using mail as the account attribute. I'll try and get a fix for that within the next few days.

[wheelybird]

@microbearlogist sorry about the delay on this. Looking at this further I realise I didn't ask an important question - do you intend to use the mail attribute as the actual account identifier, or did you just want to use the email address to log in? That is, do you want the DN to be something like dn=mail=person@place.com,ou=people,dc=place,dc=com?

[microbearlogist]

@wheelybird Only for login! For the account ID, I prefer to manage it independently for each client app. I don't know if it can be an usefull option.

[wheelybird]

Okay. So we actually need a new setting that lets you select which attribute you use to log in with, independent of the account identifier and with the caveat that you should never set it to an attribute that can hold non-unique values.

[microbearlogist]

Sounds more complicated than expected 😅 I don't know all the implications of using email as account identifier, but if it's easier for you, that's good enough.

[wheelybird]

Could you try using this image: wheelybird/ldap-user-manager:issue-209. This has two new env vars:

• SITE_LOGIN_LDAP_ATTRIBUTE (default: LDAP_ACCOUNT_ATTRIBUTE): The LDAP account attribute to use when logging into the user-manager. For example, set this to mail to use email addresses to log in. Use this with extreme caution. The value for this attribute needs to be unique for each account; if more than one result is found when searching for an account then you won't be able to log in.

• SITE_LOGIN_FIELD_LABEL (default: Username): This is the label that appears next to the username field on the login page. If you change SITE_LOGIN_LDAP_ATTRIBUTE then you might want to change this. For example, SITE_LOGIN_FIELD_LABEL="Email address".

[Norde]

With the new settings, everything works as expected (the login using email as well as the change of login field label). Thanks a lot @wheelybird 😶

[dacrudg]

Im using this as well, but when I login It just goes back to the login form as if I put in the wrong password or something.

SITE_LOGIN_LDAP_ATTRIBUTE=mail

Is set. Any my LDAP entry looks like this:

dn: uid=admin,ou=people,dc=computer,dc=com givenName: admin sn: admin uid: admin mail: admin@f11.computer.com mailAlias: admin@f11.computer.com cn: admin mailEnabled: true objectClass: person objectClass: inetOrgPerson objectClass: PostfixBookMailAccount objectClass: posixAccount userPassword:: xxxxxxxxxxxxxxxxxxxxxxxxxxxxx uidNumber: 2001 gidNumber: 2001 loginShell: /bin/bash homeDirectory: /home/admin structuralObjectClass: inetOrgPerson memberOf: cn=admins,ou=groups,dc=computer,dc=com memberOf: cn=everybody,ou=groups,dc=computer,dc=com entryUUID: 3bcada40-c414-103d-9a79-db1db45140a6 creatorsName: cn=admin,dc=computer,dc=com createTimestamp: 20230731173423Z entryCSN: 20230731173423.588988Z#000000#000#000000 modifiersName: cn=admin,dc=computer,dc=com modifyTimestamp: 20230731173423Z

[dacrudg]

Nevermind just got it working. Thanks