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. >> >> > > -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ _______________________________________________ sssd-users mailing list [email protected] https://lists.fedorahosted.org/mailman/listinfo/sssd-users
