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
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.