At least in the case of 3.6, it seems this is my problem: Error loading module '/usr/local/samba/lib/idmap/ad.so': /usr/local/samba/lib/idmap/ad.so: cannot open shared object file: No such file or directory
Indeed, it does not exist: [root@ALW2 ~]# find /usr/local/samba/|grep ad.so /usr/local/samba/lib/vfs/readahead.so /usr/local/samba/lib/vfs/readahead.so.old [root@ALW2 ~]# find install_files/samba3/samba-3.6.10/|grep ad.so install_files/samba3/samba-3.6.10/source3/bin/readahead.so I recompiled --with-ads, but it made no difference. On Mon, Dec 17, 2012 at 8:42 AM, Thomas Simmons <[email protected]> wrote: > Hello, > > I was able to get back to the original (incorrect "4294967295") uids/gids > on the 4.0 member with 'net cache flush'. I remove the 4.0 member from the > domain, compiled 3.6.10 and re-joined. Unfortunately, that doesn't work > either. I have no idea what to do at this point. > > 3.6.10 output > > [root@ALW2 samba]# wbinfo -u > administrator > tuser1 > tuser2 > tuser3 > krbtgt > guest > > [root@ALW2 samba]# wbinfo -i tuser1 > failed to call wbcGetpwnam: WBC_ERR_DOMAIN_NOT_FOUND > Could not get info for user tuser1 > > [root@ALW2 samba]# getent passwd|grep tuser1 > [root@ALW2 samba]# > > [root@ALW2 samba]# smbclient -Llocalhost -UAdministrator%P4\$\$w0rd > session setup failed: NT_STATUS_LOGON_FAILURE > > My 3.6.10 smb.conf: > > [global] > workgroup = TESTDOM > realm = internal.testdom.com > preferred master = no > server string = ALW2 > security = ads > encrypt passwords = yes > > idmap config TESTDOM : default = yes > idmap config TESTDOM : backend = ad > idmap config TESTDOM : schema_mode = rfc2307 > idmap config TESTDOM : range = 100000-200000 > > winbind enum users = yes > winbind enum groups = yes > winbind nested groups = yes > winbind use default domain = yes > > template homedir = /home/%U > template shell = /bin/sh > > If I add (and change nothing else): > * > * > * idmap config * : range = 30000-40000* > * idmap config * : backend = tdb* > > [root@ALW2 samba]# wbinfo -i tuser1 > tuser1:*:30005:30006:Test User1:/home/tuser1:/bin/sh > > [root@ALW2 samba]# getent passwd|grep tuser > tuser1:*:30005:30006:Test User1:/home/tuser1:/bin/sh > tuser2:*:30001:30006:Test User2:/home/tuser2:/bin/sh > tuser3:*:30002:30006:Test User3:/home/tuser3:/bin/sh > > [root@ALW2 samba]# smbclient -L localhost -U Administrator%P4\$\$w0rd > Domain=[TESTDOM] OS=[Unix] Server=[Samba 3.6.10] > > Sharename Type Comment > --------- ---- ------- > IPC$ IPC IPC Service (ALW2) > Domain=[TESTDOM] OS=[Unix] Server=[Samba 3.6.10] > > Server Comment > --------- ------- > > Workgroup Master > --------- ------- > > > > > > On Sun, Dec 16, 2012 at 8:35 PM, Thomas Simmons <[email protected]> wrote: > >> I am seeing similar behavior on an S4 member server. In this case, every >> uid and gid is reported as "4294967295". As best I can tell, my smb.conf is >> ok. >> >> [root@ALW2 etc]# wbinfo -u >> administrator >> tuser1 >> tuser2 >> tuser3 >> krbtgt >> guest >> >> [root@ALW2 etc]# wbinfo -i tuser1 >> tuser1:*:4294967295:4294967295:Test User1:/home/tuser1:/bin/sh >> >> [root@ALW2 etc]# getent passwd|grep tuser >> tuser1:*:4294967295:4294967295:Test User1:/home/tuser1:/bin/sh >> tuser2:*:4294967295:4294967295:Test User2:/home/tuser2:/bin/sh >> tuser3:*:4294967295:4294967295:Test User3:/home/tuser3:/bin/sh >> >> >> [global] >> workgroup = TESTDOM >> realm = internal.testdom.com >> preferred master = no >> server string = ALW2 >> security = ads >> encrypt passwords = yes >> >> idmap config TESTDOM:backend = ads >> idmap config TESTDOM:schema_mode = rfc2307 >> idmap config TESTDOM:range = 1000-999999 >> >> winbind enum users = yes >> winbind enum groups = yes >> winbind nested groups = yes >> winbind use default domain = yes >> >> template homedir = /home/%U >> template shell = /bin/sh >> >> If I add: >> >> idmap backend = tdb >> idmap uid = 1000000-1999999 >> idmap gid = 1000000-1999999 >> >> then I get uids and gids generated from this range. When I remove the >> options, my users keep the generated uids and gids. I'm not sure how to >> revert? >> >> >> Thank you all for your help. >> >> >> On Sun, Dec 16, 2012 at 5:32 PM, Thomas Simmons <[email protected]>wrote: >> >>> acl:search = false is commented out there, but the behavior is the same >>> either way. >>> >>> >>> On Sun, Dec 16, 2012 at 5:30 PM, Thomas Simmons <[email protected]>wrote: >>> >>>> I am using 'template homedir' and 'template shell' for these >>>> attributes, which I'm fine with. It's the uidNumber and gidNumber that >>>> I'm primarily concerned with. My global section: >>>> >>>> [global] >>>> workgroup = TESTDOM >>>> realm = internal.testdom.com >>>> netbios name = ADC1 >>>> server role = active directory domain controller >>>> dns forwarder = 10.10.65.1 >>>> idmap_ldb:use rfc2307 = yes >>>> #acl:search = false >>>> >>>> template homedir = /home/%ACCOUNTNAME% >>>> template shell = /bin/sh >>>> >>>> >>>> >>>> On Sun, Dec 16, 2012 at 5:06 PM, Andrew Bartlett <[email protected]>wrote: >>>> >>>>> On Sun, 2012-12-16 at 16:51 -0500, Thomas Simmons wrote: >>>>> > Hello Andrew, >>>>> > >>>>> > >>>>> > If functionality is not there, I certainly understand and can work >>>>> > around it. I just want to make sure I am not misunderstanding >>>>> > something. >>>>> > >>>>> > >>>>> > When you say I should set "idmap_ldb:use rfc2307=yes" in smb.conf on >>>>> > the DC, do you mean that by doing so I can use winbind (and the >>>>> > rfc2307 attributes) for *nix authentication on the DC? I am confused >>>>> > because I already have "idmap_ldb:use rfc2307 = yes" in my smb.conf >>>>> > (it gets added automatically with the classicupgrade and I always >>>>> > provision my "clean" test setup with "--use-rfc2307"). That actually >>>>> > works fine - the rfc2307 attributes are there and I can modify them >>>>> in >>>>> > ADUC. If I configure the server to use NSS+LDAP for authentication, >>>>> my >>>>> > users's uid number, gid number, shell, etc are what I have specified >>>>> > in ADUC. When I try using winbind, it is not using the rfc2307 >>>>> > information from AD. >>>>> >>>>> That's odd, but remember that only the UID and GID values will be used >>>>> (not the shell or homedir, which is handled in a different bit of the >>>>> code). However, your output below clearly shows that isn't >>>>> happening :-( >>>>> >>>>> > > Here I have NSS+LDAP configured and getent reports the >>>>> correct uidNumber >>>>> > > and gidNumber that I have specified in AD (rfc2307 >>>>> attributes): >>>>> > > >>>>> > > root@ALW1:~# getent passwd | grep tuser >>>>> > > tuser1:*:10005:10000:Test User1:/home/tuser1:/bin/sh >>>>> > > tuser2:*:10006:10000:Test User2:/home/tuser2:/bin/sh >>>>> > > tuser3:*:10007:10000:Test User3:/home/tuser3:/bin/sh >>>>> > > >>>>> > > Here (DC) I am using winbind for authentication, and getent >>>>> does not report >>>>> > > the correct uidNumber and gidNumber: >>>>> > > >>>>> > > [root@ADC1 ~]# getent passwd | grep tuser >>>>> > > TESTDOM\tuser1:*:3000025:100:Test >>>>> User1:/home/tuser1:/bin/sh >>>>> > > TESTDOM\tuser2:*:3000026:100:Test >>>>> User2:/home/tuser2:/bin/sh >>>>> > > TESTDOM\tuser3:*:3000027:100:Test >>>>> User3:/home/tuser3:/bin/sh >>>>> > >>>>> As a test, can you set 'acl:search=false' and see if it makes a >>>>> difference? >>>>> >>>>> > Initially, "idmap_ldb:use rfc2307 = yes" was the only idmap related >>>>> > entry in my smb.conf. When that did not work I tried a bunch of other >>>>> > "idmap config DOMAIN" settings. >>>>> >>>>> The code that handles that isn't hooked up yet. I'm hoping someone >>>>> will >>>>> take this on for 4.1. >>>>> >>>>> > Again, if this simply does not work at this time, I can use NSS and >>>>> > LDAP for logins on my DCs. With my S3 setup, I've always used LDAP >>>>> for >>>>> > auth on *nix systems and am not terribly familiar with winbind, so I >>>>> > just want to make sure I'm not missing something. My next test will >>>>> be >>>>> > setting up a member server. Can you tell me what entries I will need >>>>> > in my smb.conf to have winbind use the rfc2307 information from my S4 >>>>> > DC on member servers? >>>>> >>>>> I don't recall the exact settings right now, but for member servers it >>>>> is the same as for a Windows AD domain (yes, I think this should be >>>>> more >>>>> automatic). >>>>> >>>>> In terms of using nss_ldap on the DC, the only concern I have is that >>>>> the [homes] share might not work if you do that. Our DC code mostly >>>>> avoids calling into nss, but that particular area does do it, and >>>>> really >>>>> does expect that nss_winbind is being used. >>>>> >>>>> For that reason, we generally suggest separation between the DC and >>>>> other roles as the best way out of this situation. >>>>> >>>>> Andrew Bartlett >>>>> >>>>> -- >>>>> Andrew Bartlett >>>>> http://samba.org/~abartlet/ >>>>> Authentication Developer, Samba Team http://samba.org >>>>> >>>>> >>>>> >>>> >>> >> > -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
