The Samba-Bugzilla – Bug 9795
samba 4 winbind works differently than earlier versions
Last modified: 2016-04-08 08:03:40 UTC
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:
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:
uid=3000017(user) gid=3000000(domain_users) groups=3000000(domain_users)
Whilst on the S4 server, the same two commands return:
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)
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:
Primary group name/GID
you get in the users info:
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.