On Mon, Jul 17, 2006 at 10:23:41PM +0200, Holger Wesser wrote: > "New handling of unmapped users and groups" > > what does this mean?
This means that we have cleaned up a big mess that has caused very difficult to diagnose problems for quite a number of people. It comes down to a different handling of interconnecting the different concepts Windows and Unix have about users and groups. Under Windows users, groups and lots of other stuff is represented by security identifiers. These are the S-1-5-21-x-y-z-512 things you seen in 'net groupmap'. Saying Windows has 128-bit long user and group IDs is technically not fully correct, but approximates it quite well. We always have the problem to a) squeeze the 128-bit space into the 32 bits unix provides us and b) the other way round, invent 128-bit SIDs from the 32-bit unix IDs. In the various scenarios that we have to live in this turns out to be quite difficult: * Samba as a standalone server has to invent SIDs from unix IDs. This is not too difficult, historically this has been done with the so-called algorithmic mapping: We invented a random x-y-z for the machine and created a user sid by <uid>*2+1000 and a group sid by <gid>*2+1001. * Samba as a member server has to work with SIDs presented by others, namely domain controllers. It's not only one domain, the domain controller we use as "ours" can all of the sudden trust another domain. For this task winbind maintains a static table, the winbindd_idmap.tdb with its remote backends. * Samba as a domain controller has to provide both tasks: For the users/groups it is responsible for itself has to invent SIDs and for the SIDs it imports from trusted domain controllers it has to invent uids/gids. These abstract tasks are a there, like it or not. We have to solve them. Before 3.0.23 it has been a BIG mess that led to inconsistent mappings in different situations. For example it was not possible to get reasonable local (nested) group support in Samba with that code, so some clean up had to be done. In fact, a big Samba user complaining that nested groups did not work made me fix all this. You are facing the only incompatible change that we had to introduce: You are not seeing the groups your users are in anymore without mapping them with the net sam mapunixgroup utility. One thing you could do for example is: getent group | cut -d : -f 1 | xargs -n 1 net sam mapunixgroup This does the explicit mapping for all unix groups you have in /etc/passwd and/or nss_ldap. If this still does not help, we need your smb.conf and a full debug level 10 log of smbd, running usrmgr.exe into the error. Volker
pgpo0mVJ4WF2J.pgp
Description: PGP signature
-- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/listinfo/samba
