Bug 9795 - samba 4 winbind works differently than earlier versions
Summary: samba 4 winbind works differently than earlier versions
Alias: None
Product: Samba 4.0
Classification: Unclassified
Component: Winbind (show other bugs)
Version: unspecified
Hardware: All All
: P5 normal (vote)
Target Milestone: ---
Assignee: Samba QA Contact
QA Contact: Samba QA Contact
Depends on:
Reported: 2013-04-15 18:16 UTC by Rowland Penny
Modified: 2016-04-08 08:03 UTC (History)
4 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Rowland Penny 2013-04-15 18:16:51 UTC

Comment 1 Rowland Penny 2013-04-15 18:21:18 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
Comment 2 Rowland Penny 2013-04-16 13:47:46 UTC
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:

id 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
Comment 3 Rowland Penny 2013-04-16 14:23:44 UTC
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)

Comment 4 Michael Adam 2013-04-18 10:05:39 UTC
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
Comment 5 Rowland Penny 2013-04-18 17:44:55 UTC
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
Login Shell
Home Directory
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.
Comment 6 Björn Jacke 2016-04-08 08:03:40 UTC
as the "winbind 4" were merged into the old "main" winbind implementation, we can close this now I think.