I cannot get windbind on S3 to give me the same uidNumber & gidNumber as the samba 4 winbind, no matter what backend I use and/or range. My suggestion would be to either make the S3 & S4 winbinds work the same or to make winbind on S4 optional
OK, not being one to give up, I have been doing further testing with winbind on 3.6.6 from LinuxMint 14 and have got it to work, to some extent, I have been folowing various howto's and postings on found on the net. If I use this smb.conf on the client against samba 4.0.4: [global] workgroup = DOMAIN realm = DOMAIN.LAN server string = %h server (Samba) security = ADS allow trusted domains = No restrict anonymous = 2 dedicated keytab file = /etc/krb5.keytab kerberos method = secrets and keytab syslog = 0 log file = /var/log/samba/samba.log max log size = 4192 local master = No domain master = No idmap cache time = 120 idmap negative cache time = 1 template shell = /bin/bash winbind enum users = Yes winbind enum groups = Yes winbind use default domain = Yes winbind expand groups = 4 winbind nss info = rfc2307 winbind refresh tickets = Yes winbind normalize names = Yes idmap config *:schema_mode = rfc2307 idmap config *:range = 3000000-3100000 idmap config * : backend = tdb I get this from getent passwd user: user:*:3000017:3000000:user:/home/DOMAIN/user:/bin/bash id user: uid=3000017(user) gid=3000000(domain_users) groups=3000000(domain_users) Whilst on the S4 server, the same two commands return: HOME\user:*:3000017:100::/home/HOME/user:/bin/bash uid=3000017(HOME\user) gid=100(users) groups=100(users) So a step in the right direction, I now get the correct uidNumber but the gidNumber is wrong. I only got to the above smb.conf in frustration after trying every permutation of idmap_ad idmap config DOMAIN: I could think of, none of which worked. Would it not be better if samba was configured with 'security = ADS' then winbind just pulled the users info from ldap, uidnumbers etc
OK, I spoke too soon, if I add new users to the S4 AD then on the S3 client, their uidNumbers reported by Getent passwd start at 3000000. Strange that users already in the database get the right uidnumber reported. I am beginning to hate winbind with a passion ;-) (sorry if that upsets anybody) Rowland
Hi Rowland, thanks for taking the time to log this as a bug report! It is not a current feature to have the same Unix ID associated to a given Windows-level user on a Samba4 DC and on a Samba3 member, not even on two replicating Samba4 DCs in the same domain. The unix IDs (or more precisely the id-mappings) are currently not part of the Active Directory database. This usually also not necessary. (It might give you feeling of safety though.) What you can achieve is to have the same unix ids on all samba member servers, by e.g. using the rid or autorid idmap backends in the winbindd configuration. One theoretical possibility for achieving what you are asking for is using the SFU posix attributes in AD for assigning unix IDs to the Windows-Level users and groups. Then a member server could use the same ids by virtue of the "ad" idmap backend. We have thought about this, but there are several non-trivial problems associated to it: - sfu attributes are intended to be filled by the administrator via the windows gui, but we need the users and groups to have unix ids assigned automatically after their creation, or at least before their first access to the file server. - but automatically assigning sfu ids is problematic at least in a multi-dc-environment, because there is no SFU-Master-Role in the windows AD concepts, so there is the danger of collisions. - even if we can solve this, it is currently not easily possible to use the SFU-Unix-IDs with samba4, because samba 4 needs the id mapping type "BOTH" (i.e. a sid is mapped to both a user and a group id) in order to properly server the sysvol share for group policy. One might need to restrict the SFU unix id mechanism in a way that would make it incompatible with windows. I don't say it can't be achieved, but at least it is not trivial and needs some careful thought. So do you really _need_ the feature? If yes, for what purpose? Or would you just feel more comfortable? Cheers - Michael
OK, I think I know what the problem is, winbind requires posixAccount & posixGroup objectclasses. If you add the following, via the UNIX Attributes tab in ADUC: NIS Domain UID Login Shell Home Directory Primary group name/GID you get in the users info: msSFU30NisDomain uidNumber loginShell unixHomeDirectory gidNumber msSFU30Name unixUserPassword uid What you do not get is the posixAccount objectclass without the posix objectclass, winbind on S4 ignores the Unix attributes. I can accept that in the short term I will have to add the Unix attributes manually for linux clients, but I think that S4 winbind needs to be altered to not require the posix objectclasses that Windows does not add.
as the "winbind 4" were merged into the old "main" winbind implementation, we can close this now I think.