[SOLVED] Linux UID vs. Samba IDMAP ID mismatch causes access problems

smguenther · February 27, 2019, 4:26pm

Hello,

we have a strange problem on a UCS 4.3.3 where freshly created users can’t access their home directory.

The problem is, that the new account has the linux uid 2320 and the home directory is owned by this user/id.
But when the user creates a new file, this file is owned by the uid 3000234 which is within the range of the idmap config in /etc/samba/smb.conf.
Since 3000234 doesn’t equal 2320, the user cannot access the home directory from the windows pc.

Does anyone have an idea what causes this mismatch and how we can solve it permanently?

Thanks for any suggestions,

Stefan

Moritz_Bunkus · February 27, 2019, 4:29pm

Try restarting your winbind daemon.

smguenther · February 27, 2019, 4:31pm

We already did a complete restart of the server.

Moritz_Bunkus · February 27, 2019, 4:35pm

OK, then please post the output of the following commands:

wbinfo --uid-to-sid 2320
wbinfo --sid-to-uid $(wbinfo --uid-to-sid 2320)
ldbsearch -H /var/lib/samba/private/idmap.ldb '(&(xidnumber=2320)(type=ID_TYPE_UID))'
univention-ldapsearch -LLLo ldif-wrap=no uidnumber=2320 sambaSID
univention-s4search objectSid=$( univention-ldapsearch -LLLo ldif-wrap=no uidnumber=2320 sambaSID | awk '/^sambaSID:/ { print $2 }') dn

smguenther · February 27, 2019, 4:48pm

root@samba:/# wbinfo --uid-to-sid 2320
S-1-4-2320

root@samba:/# ldbsearch -H /var/lib/samba/private/idmap.ldb '(&(xidnumber=2320)(type=ID_TYPE_UID))'
GENSEC backend 'gssapi_spnego' registered
GENSEC backend 'gssapi_krb5' registered
GENSEC backend 'gssapi_krb5_sasl' registered
GENSEC backend 'spnego' registered
GENSEC backend 'schannel' registered
GENSEC backend 'naclrpc_as_system' registered
GENSEC backend 'sasl-EXTERNAL' registered
GENSEC backend 'ntlmssp' registered
GENSEC backend 'ntlmssp_resume_ccache' registered
GENSEC backend 'http_basic' registered
GENSEC backend 'http_ntlm' registered
GENSEC backend 'krb5' registered
GENSEC backend 'fake_gssapi_krb5' registered
# record 1
dn: CN=S-1-4-2320
cn: S-1-4-2320
objectClass: sidMap
objectSid: S-1-4-2320
type: ID_TYPE_UID
xidNumber: 2320
distinguishedName: CN=S-1-4-2320

# returned 1 records
# 1 entries
# 0 referrals

root@samba:/# univention-ldapsearch -LLLo ldif-wrap=no uidnumber=2320 sambaSID
dn: uid=test,cn=users,dc=rastatt,dc=de
sambaSID: S-1-5-21-977411271-997442558-3186348870-1434

root@samba:/home/transfer# univention-s4search objectSid=$( univention-ldapsearch -LLLo ldif-wrap=no uidnumber=2320 sambaSID | awk '/^sambaSID:/ { print $2 }') dn
GENSEC backend 'gssapi_spnego' registered
GENSEC backend 'gssapi_krb5' registered
GENSEC backend 'gssapi_krb5_sasl' registered
GENSEC backend 'spnego' registered
GENSEC backend 'schannel' registered
GENSEC backend 'naclrpc_as_system' registered
GENSEC backend 'sasl-EXTERNAL' registered
GENSEC backend 'ntlmssp' registered
GENSEC backend 'ntlmssp_resume_ccache' registered
GENSEC backend 'http_basic' registered
GENSEC backend 'http_ntlm' registered
GENSEC backend 'krb5' registered
GENSEC backend 'fake_gssapi_krb5' registered
# record 1
dn: CN=test,CN=Users,DC=rastatt,DC=de

# Referral
ref: ldap://rastatt.de/CN=Configuration,DC=rastatt,DC=de

# Referral
ref: ldap://rastatt.de/DC=DomainDnsZones,DC=rastatt,DC=de

# Referral
ref: ldap://rastatt.de/DC=ForestDnsZones,DC=rastatt,DC=de

# returned 4 records
# 1 entries
# 3 referrals

THX!

Stefan

Moritz_Bunkus · February 27, 2019, 4:56pm

The content from the univention-ldapsearch and univention-s4search look fine, but the ID mapping is obviously wrong. The output of the first command and of the ldbsearch should be the sambaSID from the univention-ldapsearch.

Do you have S4 connector rejects (univention-s4connector-list-rejected)?

Does this problem persist with accounts created after that server restart you mentioned? If you don’t have such an account, please create one. You have to verify that the sambaSID output by univention-ldapsearch uidNumber=<yourNewUser'sUID> sambaSID is the same as what’s output by ldbsearch -H /var/lib/samba/private/idmap.ldb '(&(xidnumber=<yourNewUser'sUID>)(type=ID_TYPE_UID))'

If accounts created after said server restart are fine, we can concentrate on fixing existing bad mappings.

smguenther · February 27, 2019, 7:19pm

root@samba:~# univention-s4connector-list-rejected

UCS rejected

    1:   UCS DN: <NORESYNC=broken file:1536142999.874840>;unknown
          S4 DN: <not found>
         Filename: /var/lib/univention-connector/s4/1536142999.874840

    2:   UCS DN: <NORESYNC=broken file:1536143000.146513>;unknown
          S4 DN: <not found>
         Filename: /var/lib/univention-connector/s4/1536143000.146513

    3:   UCS DN: <NORESYNC=broken file:1536143000.191288>;unknown
          S4 DN: <not found>
         Filename: /var/lib/univention-connector/s4/1536143000.191288

    4:   UCS DN: <NORESYNC=broken file:1536143000.224616>;unknown
          S4 DN: <not found>
         Filename: /var/lib/univention-connector/s4/1536143000.224616

    5:   UCS DN: <NORESYNC=broken file:1536143000.258228>;unknown
          S4 DN: <not found>
         Filename: /var/lib/univention-connector/s4/1536143000.258228

    6:   UCS DN: <NORESYNC=broken file:1536143000.414626>;unknown
          S4 DN: <not found>
         Filename: /var/lib/univention-connector/s4/1536143000.414626

    7:   UCS DN: <NORESYNC=broken file:1536143000.629398>;unknown
          S4 DN: <not found>
         Filename: /var/lib/univention-connector/s4/1536143000.629398

S4 rejected
        last synced USN: 65755

But none of the mentioned files exists.
And even after the reboot, a newly created user has no access to its home directory:

root@samba:/var/log/univention# smbclient //localhost/test2 -U test2        
Enter RASTATT\test2's password: 
Try "help" to get a list of possible commands.
smb: \> ls
NT_STATUS_ACCESS_DENIED listing \*

Regards,

Stefan

Moritz_Bunkus · February 28, 2019, 8:57am

You can get rid of such bogus entries by removing them from /etc/univention/connector/s4internal.sqlite (make a backup before changing anything and stop the univention-s4connector service while you’re changing the file).

Can you show my all relevant logs for your new user test2 from /var/log/univention/connector-s4.log, please? I don’t expect anything interesting will show up there as the content of the S4 LDAP looked OK in the output you posted earlier, but better safe than sorry.

If I remember correctly the entries in idmap.ldb should be set up by the S4 connector. You should probably do the following:

Stop the S4 connector service
Remove the offending entries from s4internal.sqlite
Increase the log level for the connector via ucr set connector/debug/level=4
Restart the S4 connector service
Remove all users with such broken ID mapping via the UMC (you can check which users those are by looking at the output of ldbsearch -H /var/lib/samba/private/idmap.ldb ; only those with short SIDs and who are not well-known/built-in users such as administrator are relevant)
Add another new test user

Then post the output of /var/log/univention/connector-s4.log generated after creating the latest test user in step 6.

Afterwards you should decrease the log level again and restart the S4 connector service.

Moritz_Bunkus · February 28, 2019, 9:08am

Addendum: oh wait, the S4 connector is the wrong component here — the directory listener service is the one populating the ID mapping database. So do everything I wrote about above, but on top of that please run the following:

ucr set listener/debug/level=4
systemctl restart univention-directory-listener.service
ps uw -u listener
univention-directory-listener-ctrl resync samba4-idmap

Afterwards the corresponding log file /var/log/univention/listener.log will contain a lot of output you can analyze further. Note that there’s a delay between issuing the resync command and the process actually starting (and therefore the log file containing information). Give it a minute or two.

The ps is there only for you to make sure the process is actually running. The output should contain something like this:

listener 15912  5.6  1.3 2905348 84560 ?       S    10:06   0:07 /usr/sbin/univention-directory-listener -F -d 4 -b dc=mbu-test,dc=intranet -m /usr/lib/univention-directory-listener/system…

smguenther · March 1, 2019, 9:38pm

Could this lines from /var/log/univention/listener.log point to a damaged file, causing then problems:

25.02.19 08:25:07.322  LISTENER    ( PROCESS ) : updating 'uid=test,cn=users,dc=rastatt,dc=de' command m
ltdb: tdb(/var/lib/samba/private/idmap.ldb): tdb_rec_read bad magic 0xd9fee666 at offset=1478012
25.02.19 08:25:07.345  LISTENER    ( WARN    ) : Indexed and full searches both failed!
ltdb: tdb(/var/lib/samba/private/idmap.ldb): tdb_rec_read bad magic 0xd9fee666 at offset=1478012
25.02.19 08:25:07.345  LISTENER    ( ERROR   ) : Indexed and full searches both failed!
ltdb: tdb(/var/lib/samba/private/idmap.ldb): tdb_rec_read bad magic 0xd9fee666 at offset=1478012
25.02.19 08:25:07.346  LISTENER    ( ERROR   ) : Indexed and full searches both failed!

But how can I repair var/lib/samba/private/idmap.ldb?

Moritz_Bunkus · March 4, 2019, 8:37am

Hey,

yes, that’s definitely an indicator for damaged files & should never happen. One thing you can do at this point is to re-provision the whole Samba 4 domain from the data in your LDAP server. Be sure to make backups of /var/lib/samba before you attempt that.

m.

Andreas_T · March 4, 2019, 10:35am

We had a problem with Posix ID vs. Samba SID mismatch recently. /var/lib/samba/private/idmap.ldb showed the correct mapping, but it seems like Samba caches that information for some time (even after reboots). Use net cache list to list existing entries and net cache flush to delete the cache.

Moritz_Bunkus · March 4, 2019, 10:38am

While what you’re saying about caching is true, this is irrelevant for the case at hand as the contents of idmap.ldb are clearly wrong as ldbsearch shows. ldbsearch does not cache anything.

Additionally the error messages from the listener log file clearly indicate a damaged file. Keeping on using it is clearly dangerous.

smguenther · March 15, 2019, 8:23am

We found a much easier solutions to solve the problem, without re-provisioning the server.

Since the listener complained about errors in /var/lib/imap/private/idmap.ldb I opened the file with vi, to check the content:

ldbedit -e vi -H /var/lib/samba/private/idmap.ldb

I didn’t not find any errors but nevertheless decided to save the file and not just leave it. This obviously saved the file in an error free state and listener now is able to read the file again.

Thanks for your help,

Stefan

Moritz_Bunkus · March 15, 2019, 9:40am

That isn’t a solution, that’s wishful thinking. You don’t know how much data wasn’t readable from the file. It’s highly likely at least some parts of the file couldn’t be read, weren’t present in your edit session and are therefore permanently lost.

Sure, you can continue with your setup, but be prepared for issues further down the road.

That being said, you should be able to verify if there are entries missing. I’ve whipped up a script that can verify the presence and correctness of all entries in idmap.ldb by comparing its contents to the users & groups present in the OpenLDAP. Simply download it & run it.