-----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 >>>>>> [email protected] >>>>>> 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 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. 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 [email protected] https://lists.fedorahosted.org/mailman/listinfo/sssd-users
