Bug 13598 - LDAP simple bind error for users with @ in the samAccountName
Summary: LDAP simple bind error for users with @ in the samAccountName
Alias: None
Product: Samba 4.1 and newer
Classification: Unclassified
Component: AD: LDB/DSDB/SAMDB (show other bugs)
Version: 4.12.5
Hardware: All All
: P5 regression (vote)
Target Milestone: ---
Assignee: Andrew Bartlett
QA Contact: Samba QA Contact
URL: https://gitlab.com/samba-team/samba/-...
Depends on:
Reported: 2018-09-01 13:58 UTC by Dinu-Razvan Chis-Serban
Modified: 2020-08-18 08:45 UTC (History)
1 user (show)

See Also:

samba-debug-info.txt (11.97 KB, text/plain)
2019-06-27 12:14 UTC, Dinu-Razvan Chis-Serban
no flags Details
samba-debug-info.txt (7.99 KB, text/plain)
2019-07-03 19:55 UTC, Dinu-Razvan Chis-Serban
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Dinu-Razvan Chis-Serban 2018-09-01 13:58:35 UTC

I have upgraded my domain controllers OS from Ubuntu 17.10 (with Samba 4.6.7) to Ubuntu 18.04 (with Samba 4.7.6) only to find out that all my accounts (virtual email accounts) have stopped working.

I have tested it with 
ldapsearch -H ldaps://dc1.sdomain.domain.com -D 'CN=user@domain.com,OU=Accounts,DC=sdomain,DC=domain,DC=com' -W

The error was
    ldap_bind: Invalid credentials (49)
            additional info: 80090308: LdapErr: DSID-0C0903A9, comment: AcceptSecurityContext error, data 52e, v1db1

So I have restored them from backup and I have made a third new one on Fedora 28 with Samba 4.8.5 to test the functionality (I have joined it to the same domain as the Ubuntu ones).

After a few tests I find out that only CN's that have . (dot) in them have this problem and if I replace the dot with underscore they work normally.
Comment 1 Dinu-Razvan Chis-Serban 2019-06-26 06:29:05 UTC
Version 4.10.4 and the bug is still there.
Comment 2 Louis 2019-06-26 09:58:53 UTC
can you run this script on you ubuntu server. 

wget https://raw.githubusercontent.com/thctlo/samba4/master/samba-collect-debug-info.sh |bash 

And post the output in the bugreport. anonimze it where needed.
Comment 3 Dinu-Razvan Chis-Serban 2019-06-27 12:14:57 UTC
Created attachment 15268 [details]
Comment 4 Louis 2019-06-28 07:39:14 UTC
Hai, thank for the added info. 
And good to know it also runs on a RH server. :-) 

I had a look at it, that looks good, just a few comments. 

dsdb:schema update allowed = Yes
winbind enum users = Yes
winbind enum groups = Yes
wins support = Yes
preferred master = Yes

You can remove these all, 
the AD-DC is not a wins server ( wins support = yes ) 
NMBD is not running, ( preferred master = Yes ) 
The enum user/group can be turned off after testing, ( it slows down you AD-DC ) 
And the schema update can be turned off after you applied an update.  (dsdb:schema update allowed = Yes) 

The bind config,
auth-nxdomain	no;    # conform to RFC1035

You server is the autorive server for the AD-zone, so set that to yes. 

Now your error. 
Your ldap search error is: the Distinguished Name (DN) or the password is invalid.
this might be something within the RH packages, because om my debian/ubuntu servers, i cant make it fail. 

Try this one: 
ldapsearch -H <ldaps://HOSTNAME.FQDN> -b "dc=<Domain>,dc=<TLD>" -D "<Administrator@Domain.TLD>"  -W 

Does that show output, if so, verify the distinguishedName for the user your testing with. 

So, I think your distinguishedName format, you are using now, is not correct or its really a wrong password. 

I can not make it error, except by using wrong format or password.
Comment 5 Dinu-Razvan Chis-Serban 2019-06-28 08:05:48 UTC
As I was saying in the first post, the problem appeared when I have upgraded DC1 and DC2 from Ubuntu 17.10 (Samba 4.6.7) to Ubuntu 18.04 (Samba 4.7.6). I have created DC3 in Fedora because they have the quickest update rate and the newest packages but was the same. DC1 and DC2 are still on Samba 4.6.7.

And this is what I get:

====== Test 1 =======

# ldapsearch -H ldaps://dc1.lthddom.lthd.com -D 'CN=justatest@lthd.com,CN=OTRSUsers,CN=special,OU=lthd.com,OU=Virtual E-Mail Accounts,OU=E-Mail Accounts,OU=User Accounts,OU=Accounts,DC=lthddom,DC=lthd,DC=com' -W  mail -b 'CN=justatest@lthd.com,CN=OTRSUsers,CN=special,OU=lthd.com,OU=Virtual E-Mail Accounts,OU=E-Mail Accounts,OU=User Accounts,OU=Accounts,DC=lthddom,DC=lthd,DC=com' -s base
Enter LDAP Password:
# extended LDIF
# LDAPv3
# base <CN=justatest@lthd.com,CN=OTRSUsers,CN=special,OU=lthd.com,OU=Virtual E-Mail Accounts,OU=E-Mail Accounts,OU=User Accounts,OU=Accounts,DC=lthddom,DC=lthd,DC=com> with scope baseObject
# filter: (objectclass=*)
# requesting: mail

# justatest@lthd.com, OTRSUsers, special, lthd.com, Virtual E-Mail Accounts, E-Ma
 il Accounts, User Accounts, Accounts, lthddom.lthd.com
dn: CN=justatest@lthd.com,CN=OTRSUsers,CN=special,OU=lthd.com,OU=Virtual E-Mail
 Accounts,OU=E-Mail Accounts,OU=User Accounts,OU=Accounts,DC=lthddom,DC=lthd,D
mail: justatest@lthd.com

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

====== Test 2 =======

# ldapsearch -H ldaps://dc3.lthddom.lthd.com -D 'CN=justatest@lthd.com,CN=OTRSUsers,CN=special,OU=lthd.com,OU=Virtual E-Mail Accounts,OU=E-Mail Accounts,OU=User Accounts,OU=Accounts,DC=lthddom,DC=lthd,DC=com' -W  mail -b 'CN=justatest@lthd.com,CN=OTRSUsers,CN=special,OU=lthd.com,OU=Virtual E-Mail Accounts,OU=E-Mail Accounts,OU=User Accounts,OU=Accounts,DC=lthddom,DC=lthd,DC=com' -s base
Enter LDAP Password:
ldap_bind: Invalid credentials (49)
        additional info: 80090308: LdapErr: DSID-0C0903A9, comment: AcceptSecurityContext error, data 52e, v1db1
Comment 6 Louis 2019-06-28 11:24:09 UTC
add : ntlm auth = yes to the smb.conf
Does it work now? 

from :  https://www.samba.org/samba/history/

Parameter changes

The "strict sync" global parameter has been changed from
a default of "no" to "yes". This means smbd will by default
obey client requests to synchronize unwritten data in operating
system buffers safely onto disk. This is a safer default setting
for modern SMB1/2/3 clients.

The 'ntlm auth' option default is renamed to 'ntlmv2-only', reflecting
the previous behaviour.  Two new values have been provided,
'mschapv2-and-ntlmv2-only' (allowing MSCHAPv2 while denying NTLMv1)
and 'disabled', totally disabling NTLM authentication and password

smb.conf changes

  Parameter Name                     Description             Default
  --------------                     -----------             -------
  allow unsafe cluster upgrade       New parameter           no
  auth event notification            New parameter           no
  auth methods                       Deprecated
  client max protocol                Effective               SMB3_11
                                     default changed
  map untrusted to domain            New value/              auto
                                     Default changed/
  mit kdc command                    New parameter
  profile acls                       Deprecated
  rpc server dynamic port range      New parameter           49152-65535
  strict sync                        Default changed         yes
  password hash userPassword schemes New parameter
  ntlm auth                          New values              ntlmv2-only
Comment 7 Dinu-Razvan Chis-Serban 2019-06-28 12:02:57 UTC
No. It doesn't. 
I can mention that I am using ldapsearch from openldap to do the tests.
Comment 8 Louis 2019-06-28 13:39:20 UTC

i did run the same on my mail server(s) and these have only winbind install with the ldap-utils, so thats the same for me with ldapsearch. 

Ok, so we need one that knows more about RH/Fedora. 
I dont think its a bug, but a missing package, something simple, we are missing. 
We need to wait for an other the to respond. (sorry)
Comment 9 Dinu-Razvan Chis-Serban 2019-07-03 19:55:38 UTC
Created attachment 15284 [details]

I have created a Ubuntu 19.04 docker. Same result.
Comment 10 Björn Jacke 2020-02-09 18:30:10 UTC
this is more a support case not a bug report, please try to solve this on the samba mailing list or eventually choose a commercial support option from https://www.samba.org/samba/support/
Comment 11 Andrew Bartlett 2020-02-09 21:26:21 UTC
Dinu, I'm sorry we missed this, as I think this is a bug.  As Björn indicates, the mailing list can also be a good spot for initial triage. 

As you were are able to clearly reproduce, it would be awesome if you could try Samba 4.11 or git master and confirm we haven't fixed it since.  If that still fails then do a git bisect between the last good and first failing versions.

If you could show the full ldif of an entry for the user justatest, that would be awesome, as I think I know what is going on here.

My speculation is that the samAccountName also has the @ and . in it, which might be confusing things.  Internally, once we get the LDAP Bind we convert is into an 'NT4' like login as if the authentication was coming in over NTLM or SamLogon.  

The reason I suspect that is because we, in that code-path, also check for a log-in with @ in it, to possibly become a userPrinincipalName or simplely<samAccountName>@<realm>.  The . to _ would change that from matching to not-matching your realm.

We have had some rework of the authentication stack in between those versions, but also helpfully we got the authentication logging code.  If you turn up the log level you can get the information on if we correctly mapped the user to an NT4 name or not (and what name we found). 

Some suspect commit include 5da664dbed4932ef21061ad6127b5c9047398321 and 601892457865ec636dccab708d1380d58bb04fa3 to 5da664dbed4932ef21061ad6127b5c9047398321, but your bisect will tell us more.
Comment 12 Andrew Bartlett 2020-02-09 23:35:21 UTC
I've fixed the issues and made a MR.
Comment 13 Björn Jacke 2020-05-08 18:47:47 UTC
got fixes with f231a072d5c09a61e75091c294f722622dcd45da

Please close bug reports if you checked in fixes.
Comment 14 Dinu-Razvan Chis-Serban 2020-08-12 10:38:10 UTC
Sorry for the delay but I didn't had time to test it until now. It still doesn't work. I have tested it in Samba 4.12.5 (in Ubuntu 20.10 and Fedora 32) and is doing the same as before.
Comment 15 Björn Jacke 2020-08-16 21:54:59 UTC
The ubuntu version is too old. You need to ask Canonical if you want them to fix that in their version.
Comment 16 Dinu-Razvan Chis-Serban 2020-08-17 06:44:49 UTC
The latest stable release is 4.12.6, I was talking about 4.12.5. How is that too old?
Comment 17 Andrew Bartlett 2020-08-17 08:27:57 UTC
(In reply to Dinu-Razvan Chis-Serban from comment #16)
This was fixed in master as f231a072 for Samba 4.13. 


Currently not backported to release branches, but someone certainly could cherry-pick the patch per https://wiki.samba.org/index.php/Samba_Release_Planning#Release_Branch_Checkin_Procedure

If doing that then reopen, otherwise Samba 4.13 will ship soon.
Comment 18 Dinu-Razvan Chis-Serban 2020-08-17 08:47:32 UTC
(In reply to Andrew Bartlett from comment #17)
Thank you for your reply. I'll wait for Samba 4.13.
Have a nice day.
Comment 19 Dinu-Razvan Chis-Serban 2020-08-18 08:45:53 UTC
(In reply to Andrew Bartlett from comment #17)
Thank you for showing me where the patch was.

I successfully patched Samba 4.11.6 form Ubuntu 20.04 and Samba 4.12.5 form Fedora 32 and now I can confirm that the patch is backward compatible with that versions.