On 04/11/2013 02:30 PM, Rowland Penny wrote:
> 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.
>>
>>
>
You have probably based your work on the S3 winbind, this is a separate
daemon. If you run S4 as an AD DC you do not get a separate winbind
daemon, it is now built into the samba daemon, the S3 samba daemon is
not to be confused with the S3 smbd daemon which the samba daemon runs
to get the s3fs fileserver backend. The S4 winbind seems to operate
differently from S3 winbind and has, I understand, a different code base.
On the samba 4 server setup as per the samba4 howto, running as an AD
DC, getent passwd username gives:
DOMAIN\username:*:3000017:100::/home/DOMAIN/username:/bin/bash
There does not seem to be a way to change the base for the UID (3000017)
and the GID(100) comes from the RID 513, so to use sssd with the ad
backend, the users uid produced by sssd (based on the line above) would
have to be 3000017, not what it is coming up with at the moment.
What I am doing at the moment is setting the users uidNumber etc on the
S4 server and using sssd ldap to pull the info and it does seem to work
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.