-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 04/11/2013 03:33 PM, Rowland Penny wrote:
> On 11/04/13 19:50, Dmitri Pal wrote:
>> 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 thread is too long for me to scan through and check, but are you
using:
ldap_idmap_autorid_compat = True
No, but to be honest, after trying to get winbind
to work similar to
what you are suggesting, I am off any form of idmapping, this is not how
windows works and I think that idea should be layed to rest.
in your sssd.conf? If not, that's why you're getting different IDs. By
default, we use a deterministic algorithm to create the IDs, but
winbind's autorid algorithm requires that they all start at the first
slot and go upwards from there.
All S4 winbind uid's seem to start at 3000000
and I take it they come
from the users RID, so to me, that is the way that sssd needs to work,
i.e. a user logging into any client in the domain would get the same
uid, 3000017 for instance. Also S4 winbind does not seem to use slots,
every S4 winbind starts at 3000000, so sssd again needs to be aware of
the workgroup name instead of using a number based on the SID. Setting
up sssd needs to very simple, using different idmap ranges etc is not
simple.
Also, make sure that ldap_idmap_range_min, ldap_idmap_range_max and
ldap_idmap_range_size match their equivalents in winbind. I'm not
certain if they do by default.
See sssd-ad(5) for more details (on SSSD 1.9 and later)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird -
http://www.enigmail.net/
iEYEARECAAYFAlFnFqsACgkQeiVVYja6o6PmpACfeAf8iO9HMYYkGKU4Nuq9UyRT
etwAnRAxo5ug5AsLlTL+N4LgiUMY3ytp
=4XP6
-----END PGP SIGNATURE-----
_______________________________________________
sssd-users mailing list
sssd-users(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.