The Samba-Bugzilla – Bug 7334
Feature request: s4 AD DC should use account data stored in ldap to do usermapping
Last modified: 2013-02-18 13:30:44 UTC
when the uid/uidnumber are present in the account data S4 should use them to do the mapping from windows to unix.
You mean the UIDs/GIDs on the DC itself (for other UNIX systems NSS LDAP should be fine)?
I would try the following: Set it up as normal and deactivate winbind at all using the "server services" option in "smb.conf". That means to add the following line to the global section:
server services = smb, rpc, nbt, wrepl, ldap, cldap, kdc, drepl, ntp_signd, kcc, dnsupdate
(this is the default if not specified - without "winbind").
And then use NSS LDAP which should be pointed to s4's AD directory itself.
Basically the same as with a s3 DC without winbind.
Roughly thought this should work. If not I would write to the technical mailing list (more appropriate than bugzilla). Some people as abartlet, metze, tridge, kblin ... should be able to help you.
(In reply to comment #1)
> You mean the UIDs/GIDs on the DC itself (for other UNIX systems NSS LDAP should
> be fine)?
yes. i noticed that problem when i setup s4 with roaming profiles on the s4 server.
although the users are known on the unix side too and have the uid number set
according to rfc2307 schema the files get owner uids of 3000xx (regular uidnumbers
in my dit start at 1000)
> I would try the following: Set it up as normal and deactivate winbind at all
> using the "server services" option in "smb.conf". That means to add the
> following line to the global section:
> server services = smb, rpc, nbt, wrepl, ldap, cldap, kdc, drepl, ntp_signd,
> kcc, dnsupdate
> (this is the default if not specified - without "winbind").
> And then use NSS LDAP which should be pointed to s4's AD directory itself.
> Basically the same as with a s3 DC without winbind.
i would prefer to use the systems ldapclient, but that shouldn't make a difference.
i'll try without winbind tomorrow
> Roughly thought this should work. If not I would write to the technical mailing
> list (more appropriate than bugzilla). Some people as abartlet, metze, tridge,
> kblin ... should be able to help you.
trigde pointed me here to file a bug on that so it stays on focus ;-)
as suggested I tried to run s4 with the mentioned server services. as result the windows clients started choking. i got an access denied error when i tried to do something with the rsat tools. so I reverted back to the working smb.conf for now.
abartlet, shouldn't my approach in comment 1 work? Or otherwise please point out which errors I made so that Bernd is able to make this work.
It just isn't that easy - we need to change our idmap code to use the directory again, but using the correct abstractions. I would not suggest to end users to use untested combinations of Samba3 and Samba4 like that.
We will solve this eventually, but it will take time to do properly.
abartlet, thanks for your comment. This is really your area so you know it much better than me.
Bernd, you see it isn't that easy: you could help to write a patch otherwise this will take longer.
I mark this as "Feature request" since it's an extra functionality.
abartlet, thanks for comment. funny you mention S3 - as that works the way I expect it to. or to rephrase I would expect S4 to show comparable behaviour. I have S3 running as member of a domain served by Samba4 (two different machines). Neither has anything regaring idmapping in their smb.conf, so both should be using the default logic. (and no winbind running on the S3 machine)
So when a Windows user connects to a share on S3 Samba does a getpwnam and uses the uidnumber when creating files and so on. right?if it doesn't find the user with the same username, idmapping comes into play. in my environment I can make sure, that users have the same login name on both windows and unix (especially now as both sides use the same ldap/kerberos combo).
S4 behaves different. It seems not to care about trying a lookup of the user, instead goes on and starts mapping right away. even though the machine running S4 knows all users (using the same ldap backend).
I'd suggest to first try to find a user via getpwnam, failing that check S4's own directory for the uidnumber (given that the corresponding schema is in place), failing that resort to the mapping logic.
maybe that behaviour is offered if S4 runs without winbind. but as I wrote earlier - if I remove winbind from the offered services I cannot access anything on the S4 server at all.
As I say, this is much more complex than it seems.
Samba4 is based on the idea that it's directory alone contains all the data it needs, it is not an add-on to any other data source.
I know this is very different to Samba3 - and that's just how it is. We will improve this situation, and use the unix mapping attributes that Services for Unix uses, but it's not a trivial fix.
Samba4 has also chosen not to add the complexity of trying to run 'without winbind'. While historically an option with Samba3, it creates all sorts of troubles, and won't be implemented that way in our AD domain controller.
(We may add such modes when we merge in the Samba3 file server, but that's a different matter).
thanks for clearing that up (definitely worth adding to the wiki).
using only the own directory is source sound like a good idea and will eventually clean things in our installation. for now, knowing the idea behind it should be enough.
Well, I think I close this with "WONTFIX" since as abartlet states it is very unlikely to get this fixed.
We do intend to fix this, and the local sam is one of the places we should look for the data. Also, the s3compat work (and in particular the work done to harmonise interfaces) is perhaps one way we could use the idmap_ad from the source3 code.
This is a hard bug, but a real one. We must honour the uid and gid values stored in our own sam, if the administrator has chosen to use this schema in the domain.
"Feature requests" are enhancements.
seems related to Bug#8635