On 05/04/13 19:00, Jakub Hrozek wrote:
> On Fri, Apr 05, 2013 at 05:36:32PM +0100, Rowland Penny wrote:
>> 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.
>>
> Truth be told, I've never compiled Samba from scratch myself, but the
> nssswitch libraries must be installed to /lib{,64}, are you sure there
> isn't just a configure time switch for that?
>
>
If you are talking about libnss_winbind.so, then as far as I know, no
there isn't, you just have to create the two symlinks and add
'winbind' to the passwd & group lines in /etc/nsswitch.conf and it works.
If you do add the links etc then sssd does not work on the S4 server.
As sssd seems to work better than winbind then I shall continue to use
it, but what I cannot understand is why do I seem to get the feeling
that you are trying to talk me out of using sssd.
Rowland
On the samba file server or DC there other things that file server gets
directly from winbind that sssd does not have yet.
We are concerned that this would cause issues for you that you yet have
not seen. That would be the reason.
If you are willing to continue trying and are prepared to encounter
issues and report back then we are OK.
--
Thank you,
Dmitri Pal
Sr. Engineering Manager for IdM portfolio
Red Hat Inc.
-------------------------------
Looking to carve out IT costs?