On 11/04/13 18:49, Dmitri Pal wrote:
> On 04/11/2013 10:00 AM, Rowland Penny wrote:
>> 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.
You have lost me there, are you referring to the S4 winbind built into
the S4 samba daemon?
Sorry for typo, if confused the whole thing. I meant "Samba FS + winbind"
if so, there does not seem to be any documentation anywhere that I
can
find.
As I said, I tried to get winbind on the clients working with both
id_map rid & ad backends and could not get either to work. Whatever I
use, has to come up with the same UID/GID that the S4 winbind does,
because that is what the unix server seems to require. In fact I will
state it plainly, whatever is used must produce exactly the same Unix
information as the S4 winbind.
Correct and I am curious why it did not work because we used the same
algorithm in SSSD id map translation as winbind rid uses with only one
difference - SSSD can have additional ranges to support multiple
domains. If it is a bug in SSSD it is a major one that we need to fix
ASAP. If it is a bad configuration I want to get to the core of the
problem and have a clear set of instructions how to set things up
because we need it for the next round of work we will start later this
spring-summer.
Rowland
>
> 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?