On 05/04/13 17:05, Andreas Schneider wrote:
> On Friday 05 April 2013 15:54:41 Rowland Penny wrote:
>> On 05/04/13 15:35, Jakub Hrozek wrote:
>>> 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
>>>>>>> below.
>>>>>>> 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 working'
>>>>>> (Tue Apr 2 12:52:55 2013) [sssd[be[DOMAIN]]]
[set_srv_data_status]
>>>>>> (0x0100): Marking SRV lookup of service 'AD' as 'not
resolved'
>>>>>>
>>>>>> 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
>>>>> bug.
>>>> 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.
>>>>
>>>>>>>> Rowland
>>>>>>> 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
>>>>>> it?
>>>>> 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
>>>> results:
>>>>
>>>> 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
>>>>>>> believe
>>>>>>> this could be done with "winbind nss info"
configuration option.
>>>>>> 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 be
>>>>>>>
>>>>>>> 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:
>>>>>
https://fedorahosted.org/sssd/ticket/1534
>>>>>
>>>>> 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.
> That's correct and the DC needs the 'builtin' winbind daemon for the
> DC to
> function. It will not work with the s3fs winbind.
>
>> The other is built into the samba daemon and
>> requires the creation of a couple of symlinks to use winbind in
>> /etc/nsswitch.
> What do you mean here?
If, as I do, you compile Samba 4, you have to create a couple of
symlinks:
ln -s /usr/local/samba/lib/libnss_winbind.so.2 /lib/libnss_winbind.so
ln -s /lib/libnss_winbind.so /lib/libnss_winbind.so.2
Without these, you do not get any domain users etc from getent.
>
>> 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.
> Why not? To have consitent uid/gid you just set them for each user or
> let S4
> do it for you (autoincrement). Then all you have to to on the client
> is to
> read them from the AD. You can do the same with windows and unix
> extensions
> ...
>
>
> -- andreas
>
I have tried to use winbind with idmap_rid, but I got different
results from the server. I was then advised to try idmap_ad, with this
I could not get any results at all, no matter what ranges etc I put
into smb.conf.
In my opinion, for what it is worth, If Samba want people to use
winbind, they need to sort out winbind for the clients, perhaps base
it on whatever S4 uses, reduce the choices of backend to one and make
it pull the info from the S4 database and store it locally with little
modification to the smb.conf
But then again, this is what sssd seems to do, with sssd running on
the server & linux clients I get consistent uid's etc with less in the
clients smb.conf, seemingly no ranges to worry about and just one
extra conf file to set and there is very little to set if you use the
sssd ad backend.
I am not claiming that using sssd is perfect, but it is a darn sight
better than the mess winbind is at the moment.
Rowland
The funny thing is that SSSD uses a lot of samba code under the hood ;-)
It seems to do it better than winbind itself...
--
Thank you,
Dmitri Pal
Sr. Engineering Manager for IdM portfolio
Red Hat Inc.
-------------------------------
Looking to carve out IT costs?