On 08/04/13 11:39, Jakub Hrozek wrote:
> 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.
> _______________________________________________
> sssd-users mailing list
> sssd-users(a)lists.fedorahosted.org
>
https://lists.fedorahosted.org/mailman/listinfo/sssd-users
>
OK, I admit it, I was wrong, you cannot use sssd ad mode on a Samba 4
server instead of winbind.
Everything seemed to work ok until I tried to use cifs to mount the
users homedirectory from the S4 server. It mounted ok and if you
checked the user permissions on the the server & client they matched,
both names & uid's. Getfacl showed that the user should be able to
write to the share, only the user couldn't, the user had no rights to
their own directory.
I can only assume that cifs somehow uses winbind on the server and
gets the uidnumbers that S4 winbind gives, these are different to what
sssd comes up with.
What (so far) seems to work is: use winbind on the S4 server, set the
uidNumber & gidNumber etc in the S4 LDAP for the users, no need for
posix objectclasses. Then set up sssd on the linux clients to pull
from ldap using kerberos.
Rowland
Yes that would work however another scenario that we expect to more or
less work is:
S4 DS + winbind on the server side using rid ID mapping algorythm, no
UID/GID in LDAP, client is SSSD 1.9 with AD back end and id mapping used.
That should work. What would fail are some client side utilities that
grew some interfaces to the winbind.
But we plan to address them down the road.
Thanks for investigation! It is a valuable information for us.
--
Thank you,
Dmitri Pal
Sr. Engineering Manager for IdM portfolio
Red Hat Inc.
-------------------------------
Looking to carve out IT costs?