On Fri, Apr 05, 2013 at 08:15:14PM +0100, Rowland Penny wrote:
On 05/04/13 19:46, Dmitri Pal wrote:
>On 04/05/2013 02:40 PM, Rowland Penny wrote:
>>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.
>
Could you give me some idea what sssd doesn't do that winbind does?
As far as I can see, I get (via getent):
uidNumber
gidNumber
unixhomedirectory
loginShell
There is an interface for SID to name conversion in Samba and currently
only winbind implements the interface. We wanted to have a compatible
implementation done for 1.10 but we're probably not going to make it.
I don't know exactly from the top of my head what functionality the
samba server uses this interface for. Maybe Andreas or Sumit know?
which as far as I can see is what winbind would give me.
I can create directories & files and change ownership to a domain
user &/or domain group, or in other words, I cannot tell the
difference between using winbind or sssd except for the constant
uidnumbers & gidnumbers.