On Wed, Apr 03, 2013 at 11:20:44AM +0100, Rowland Penny wrote:
> On 02/04/13 22:39, Jakub Hrozek wrote:
>> On Tue, Apr 02, 2013 at 01:42:46PM +0100, Rowland Penny wrote:
>>>> With the AD provider you shouldn't be needing any of the options
>>>> The AD provider should just default to them.
>>>> Is there a reason you are using password binds and not GSSAPI?
>>> OK, I have removed all the lines you suggested and getent stopped
>>> working, examining /var/log/sssd/sssd_DOMAIN.log gives the reason:
>>> (Tue Apr 2 12:52:55 2013) [sssd[be[DOMAIN]]] [resolve_srv_send]
>>> (0x0400): SRV resolution of service 'AD'. Will use DNS discovery
>>> domain 'DOMAIN'
>>> (Tue Apr 2 12:52:55 2013) [sssd[be[DOMAIN]]] [resolve_srv_cont]
>>> (0x0100): Searching for servers via SRV query '_ldap._tcp.DOMAIN'
>>> (Tue Apr 2 12:52:55 2013) [sssd[be[DOMAIN]]] [resolv_getsrv_send]
>>> (0x0100): Trying to resolve SRV record of '_ldap._tcp.DOMAIN'
>>> (Tue Apr 2 12:52:55 2013) [sssd[be[DOMAIN]]]
>>> [request_watch_destructor] (0x0400): Deleting request watch
>>> (Tue Apr 2 12:52:55 2013) [sssd[be[DOMAIN]]] [resolve_srv_done]
>>> (0x0020): SRV query failed: [Domain name not found]
>>> (Tue Apr 2 12:52:55 2013) [sssd[be[DOMAIN]]] [fo_set_port_status]
>>> (0x0100): Marking port 0 of server '(no name)' as 'not
>>> (Tue Apr 2 12:52:55 2013) [sssd[be[DOMAIN]]] [set_srv_data_status]
>>> (0x0100): Marking SRV lookup of service 'AD' as 'not
>>> It is trying to look up the samba domain name instead of the the DNS
>>> domain.name, re-adding the following line cures this:
>>> dns_discovery_domain = domain.lan
>> I see, this is interesting. Does the value of dns_discovery_domain
>> differ from the value of ad_domain? If not, then I would consider it a
> I must have misunderstood you, because I turned off 'ad_domain =
> domain.lan'. I have now turned it back on again and turned off the
> dns_discovery_domain line and it still works.
>>>> I think there are two options:
>>>> 1) keep using the ID mapping and tailor the configuration of the ID
>>>> mapper in the SSSD so that it generates the same output as the winbind
>>>> mapper. We've done this before, it's not the nicest looking
>>>> configuration, but it works.
>>> What sssd ID mapping seems to do is, get the last part of the SID
>>> and add a number to the front of it, is this correct? and if so
>>> where does the number come from? and is this the way Windows does
>> Correct, The first number is a hashed value of the domain part of the SID
>> and the "last part of the SID" is usually called the RID.
>> Can you check if setting ldap_idmap_autorid_compat to True would yield
>> the same IDs as winbind does? (Sorry I don't have a box with winbind
>> handy and I always forget the details).
> I have tried it and no it wouldn't, with S3 winbind I got:
> uid=21105(user) gid=20513(domain_users) groups=20513(domain_users)
> With the line added into sssd.conf and winbind turned off, I now get:
> uid=201105(user) gid=200513(domain_users) groups=200513(domain_users)
>>> When you say 'the same output as the winbind mapper', which winbind
>>> are you refering to, the winbind on the Samba 4 server or the
>>> winbind on the Samba 3 client?
>> Both actually. You really want to have the IDs consistent everywhere.
> That is the problem, the built into samba4 winbind returns different
> uid=3000016(DOMAIN\user) gid=100(users) groups=100(users)
>>>> 2) Switch to using POSIX IDs instead of mapping them from SIDs with both
>>>> winbind and SSSD. All that should be needed on the SSSD side is set:
>>>> ldap_id_mapping = False
>>>> to sssd.conf and restart the SSSD (you might need to rm the cache as
>>>> SSSD doesn't really handle UID/GID changes very well yet).
>>>> On the winbind side, I'm a little fuzzy on the details, but I
>>>> this could be done with "winbind nss info" configuration
>>> The problem here is the use of winbind, I cannot get the idmap_ad
>>> backend to work at all, and idmap_rid gives a different uid from the
>>> Samba 4 server
>> So which mapper does the S4 server use?
> I do not know, I only know it is different from the S3 winbind.
>>>> From where I am 1) sounds like easier to implement since all you'd
>>>> changing is sssd.conf
>>> I am being to think that the way forward is to stop winbind on the
>>> Samba 4 server and use sssd instead.
>> That is a noble goal and one which we wanted to accomplish in the
>> upcoming 1.10 release, but it was postponed to the next one:
>> The Samba server seems to be leveraging an interface only winbind is
>> able to serve at the moment to convert SIDs to GIDs on the server side.
>> I don't know all the details, sorry, maybe on of the Samba developers
>> lurking on this list would chime in.
> I don't understand this, by removing the S4 winbind links on the
> server and installing sssd 1.9.4, I appear to have got it to work,
> I now have consistent uid's & gid's without any real effort.
I had a short chat with the Samba Red Hat maintainer Andreas Schneider
(CC-ed) and he advised against removing winbind from the server, too.
I'm sure he'll provide a more qualified answer than I can :-)
Hi, on Samba 4 you get 2 winbind's, one is based on the S3 code base and
I think that I am right in saying that it will not start if the samba
(AD) daemon is run. The other is built into the samba daemon and
requires the creation of a couple of symlinks to use winbind in
/etc/nsswitch. So you cannot remove either of the winbind's, I just
choose not to create the symlinks, that way the samba daemon winbind
cannot interfere with getent.
As I said, using sssd with samba 4 is the only easy way that I have
found to get consistent uid's etc, there is another way using nslcd,
kstart etc but it is not really as easy as sssd.
So, unless someone can provide me a good reason why I should not do
this, I will carry on testing it on my small home network.
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.