https://community.nethserver.org/t/ns8-sogo-force-login-with-email-address/24831/41?page=3
LAM
I did a clean install today of LAM, I have the same problem as in the above post.
- If I change the user in the environment file inside the LAM module and restart, I see the (errorneous) username in the samba logs with a NT_STATUS_NO_SUCH_USER
Samba container log:
Auth: [LDAP,simple bind/TLS] user [(null)][CN=myusername,CN=Users,DC=ad,DC=mydc,DC=com] at [Sun, 12 Jan 2025 18:34:46.188511 UTC] with [Plaintext] status [NT_STATUS_NO_SUCH_USER] workstation [NSDC-MYSERVER] remote host [ipv4:xxx.xxx.xxx.xxx:0042942] mapped to [(null)][(null)]. local host [ipv4:xxx.xxx.xxx.xxx:636]
- Looking closely I saw that CN used is always “users”. Unfortunately, the admin is a valid AD user but lives in a different OU.
- If I move the admin user back to the OU users, login works.
I hope that shines some light on the LAM access problems.
SOGO - Activesync clients only.
I started searching because sometimes activesync or calendar/contacts request failed on phones.In the SOGO logs, 503 errors were visible. The 503 errors are send back to the clients and cause disconnects. Samba-dc Log lines from the 503 Sogo-activesync user session:
[1:samba1:samba-dc] Auth: [LDAP,simple bind/TLS] user [(null)][samaccountname=myuser1,dc=ad,dc=mydomain,dc=com] at [Sun, 12 Jan 2025 19:32:36.328517 UTC] with [Plaintext] status [NT_STATUS_NO_SUCH_USER] workstation [NSDC-MYSERVER] remote host [ipv4:x.x.x.x:42760] mapped to [(null)][(null)]. local host [ipv4:x.x.x.x:636]
[1:samba1:samba-dc] Auth: [LDAP,simple bind/TLS] user [NETBIOS-MYDOMAIN][cn=myuser1,cn=users,dc=ad,dc=mydomain,dc=com] at [Sun, 12 Jan 2025 19:32:36.358896 UTC] with [Plaintext] status [NT_STATUS_OK] workstation [NSDC-MYSERVER] remote host [ipv4:x.x.x.x:42778] became [NETBIOS-MYDOMAIN][Myuser1] [SID]. local host [ipv4:x.x.x.x:636]
Activesync logons fail the first time. but not every time, it’s not consistent.
The second auth request is an actual auth request.
The way I look at it now, the default 6 minute timeout forces a session disconnect.
The next client logon generates the error and forces 503 (and thus a disconnect), in the second LDAP req. is a valid working request.
Is the first request an auth request but the result is handled as an LDAP user search?
It looks like a sogo-activesync bug in a special use-case (it’s inconsistent) causing unnecessary webserver 503 errors.
Just for a future reference for others looking in the log dungeons.
No solution for the Sogo disconnect issues. Still looking into that.