I answer to myself hoping to give a clue to someone.
I realised I messed up the id mapping removing the files in
/var/lib/samba/.
Having kept a copy, I tried to recover them, but probably this must be
done with the service smbd and windbind correctly stopped, which
probably I didn't. So no help this way.
The TDB backend I was using has some advantages, but the big
disadvantage is that the mapping works quite like "first come, first
served", so the id mapping must be kept in those files, otherwise the
ids can be completely changed after the folowing login attempts. It
seems this happened on my server.
I then changed the id mapping from tdb to rid, just because I had to
start over with all permission anyway. The RID backend, for me, has the advantage that the mapping is the same on every server, if it's
configured in the same way, and the known disadvantages are not
relevant to me.
Since I was setting up a backup server, the RID was the only way, so
this accident just forced me to do what I did very quickly, and with
some disappoinment from a few users. But in the end nothing was lost
and everything was ok just in a couple of days of work.
On Mon, 2023-12-18 at 14:02 +0100, nimrod wrote:
Hi,
apparently all of a sudden a member server running Debian Buster with
Winbind in an Active Directory environment started to map the domain
users in a weird way.
Many users and group seem to have two or more names, but the same id.
But this is a problem when users try to access, because it seems they
are recognized with their right name, but the server seems instead to
expect a different wrong name.
I tried to delete /var/cache/samba/netsamlogon_cache.tdb and restart
winbind, with no improvements.
What the hell could have happened?
Best regards.
<html><head></head><body><div>I answer to myself hoping to give a clue to someone.</div><div><br></div><div>I realised I messed up the id mapping removing the files in /var/lib/samba/.</div><div><br></div><div>Having kept a copy, I tried to recover them,
but probably this must be done with the service smbd and windbind correctly stopped, which probably I didn't. So no help this way.</div><div><br></div><div>The TDB backend I was using has some advantages, but the big disadvantage is that the mapping
works quite like "first come, first served", so the id mapping must be kept in those files, otherwise the ids can be completely changed after the folowing login attempts. It seems this happened on my server.</div><div><br></div><div>I then changed the id
mapping from tdb to rid, just because I had to start over with all permission anyway. The RID backend, for me, has the advantage that the mapping is the same on every server, if it's configured in the same way, and the known disadvantages are not
relevant to me.</div><div><br></div><div>Since I was setting up a backup server, the RID was the only way, so this accident just forced me to do what I did very quickly, and with some disappoinment from a few users. But in the end nothing was lost and
everything was ok just in a couple of days of work.</div><div><br></div><div>On Mon, 2023-12-18 at 14:02 +0100, nimrod wrote:</div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div>Hi,</div><div><br></
<div>apparently all of a sudden a member server running Debian Buster with Winbind in an Active Directory environment started to map the domain users in a weird way.</div><div><br></div><div>Many users and group seem to have two or more names, but
the same id. But this is a problem when users try to access, because it seems they are recognized with their right name, but the server seems instead to expect a different wrong name.</div><div><br></div><div>I tried to delete /var/cache/samba/
netsamlogon_cache.tdb and restart winbind, with no improvements.</div><div><br></div><div>What the hell could have happened?</div><div><br></div><div>Best regards.</div><div><span></span></div></blockquote><div><br></div><div><span></span></div></body></
html>
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)