Yup, strange - right!
Samba 4.2.2
RFC2307 attributes were added as follows:
# sed -e 's/${DOMAINDN}/dc=MYDOMAIN,dc=MY,dc=TLD/g' \
-e 's/${NETBIOSNAME}/MYDOMAIN/g' \
-e 's/${NISDOMAIN}/MYDOMAIN/g' \
/usr/local/samba/share/setup/ypServ30.ldif > ypServ30-JMH.ldif
# service samba4 stop
# ldbmodify -H /usr/local/samba/private/sam.ldb ypServ30-JMH.ldif
--option="dsdb:schema update allowed"=true
Modified 55 records successfully
# service samba4 start
I have been allocating a UID for users, and a GID for groups, via RSAT
ADUC; that's it - just used the next number in sequence. For users, I
have been setting the primary group to "Domain Users" (which has had a
GID allocated via ADUC)
On DC2 (which nobody logs in to interactively), no issues.
On DC1 (which has files and people log in to via ssh), I have issues.
On 11 June 2015 at 18:07, Rowland Penny <rowlandpenny at googlemail.com>
wrote:> On 11/06/15 17:26, Jonathan Hunter wrote:
>>
>> (to clarify, in case people are skimming this thread and think it is
>> fixed..) The problem still occurs - id mappings are still being
>> overwritten.. :(
>
>
> OK, this is very strange, what version of samba and how are you adding the
> RFC2307 attributes, also what RFC2307 attributes are you adding.
>
> Rowland
> --
> To unsubscribe from this list go to the following URL and read the
> instructions: https://lists.samba.org/mailman/options/samba
--
"If we knew what it was we were doing, it would not be called
research, would it?"
- Albert Einstein
On 11/06/15 18:21, Jonathan Hunter wrote:> Yup, strange - right! > > Samba 4.2.2 > > RFC2307 attributes were added as follows: > # sed -e 's/${DOMAINDN}/dc=MYDOMAIN,dc=MY,dc=TLD/g' \ > -e 's/${NETBIOSNAME}/MYDOMAIN/g' \ > -e 's/${NISDOMAIN}/MYDOMAIN/g' \ > /usr/local/samba/share/setup/ypServ30.ldif > ypServ30-JMH.ldif > # service samba4 stop > # ldbmodify -H /usr/local/samba/private/sam.ldb ypServ30-JMH.ldif > --option="dsdb:schema update allowed"=true > Modified 55 records successfully > # service samba4 start > > I have been allocating a UID for users, and a GID for groups, via RSAT > ADUC; that's it - just used the next number in sequence. For users, I > have been setting the primary group to "Domain Users" (which has had a > GID allocated via ADUC) > > On DC2 (which nobody logs in to interactively), no issues. > > On DC1 (which has files and people log in to via ssh), I have issues. > > On 11 June 2015 at 18:07, Rowland Penny <rowlandpenny at googlemail.com> wrote: >> On 11/06/15 17:26, Jonathan Hunter wrote: >>> (to clarify, in case people are skimming this thread and think it is >>> fixed..) The problem still occurs - id mappings are still being >>> overwritten.. :( >> >> OK, this is very strange, what version of samba and how are you adding the >> RFC2307 attributes, also what RFC2307 attributes are you adding. >> >> Rowland >> -- >> To unsubscribe from this list go to the following URL and read the >> instructions: https://lists.samba.org/mailman/options/samba > >Have you checked that your users actually have uidNumber attributes ? What OS are you using ? Do you have the winbind links in place ? If you run 'getent passwd adomainuser' , does it print anything ? if you run the command on the other DC, do you get the same result ? The 3000007 ID number you refer to, is an xidNumber from idmap.ldb and is created by samba. Nothing else as far as I am aware will alter idmap.ldb, though there are a couple of files you can check for: gencache_notrans.tdb gencache.tdb If they exist, delete them and then restart samba, do this on both DCs Rowland
On 11/06/15 19:21, Jonathan Hunter wrote:> sfully > # service samba4 start > > I have been allocating a UID for users, and a GID for groups, via RSAT > ADUC; that's it - just used the next number in sequence. For users, I > have been setting the primary group to "Domain Users" (which has had a > GID allocated via ADUC) > > On DC2 (which nobody logs in to interactively), no issues. > > On DC1 (which has files and people log in to via ssh), I have issues.The idmap db will only be consulted if the object does not have either a uidNumber or gidNumber attribute. The easiest way to stop the pain is to: 1. make sure that your users have the two attributes 2. remove the idmap line in smb.conf 3. kill winbindd 4. consult nss information directly from your unique ad database using sssd HTH
Thank you Rowland. On 11 June 2015 at 19:32, Rowland Penny <rowlandpenny at googlemail.com> wrote:> Have you checked that your users actually have uidNumber attributes ?I've been working on the basis that I only need to check the users I am immediately looking at.. (i.e. if there are still users without uidNumber attributes, any issue like this would only affect those users - and I can fix those later..) But, yes - for this particular user: [root at dc1 ~]# ldapsearch -LLL -s sub -b 'dc=mydomain,dc=my,dc=tld '(uidNumber=41000)' [...] primaryGroupID: 513 [...] uid: auser msSFU30Name: auser msSFU30NisDomain: MYDOMAIN uidNumber: 41000 gidNumber: 61000 unixHomeDirectory: /home/auser loginShell: /bin/sh [...]> What OS are you using ?CentOS 6.6> Do you have the winbind links in place ?Yup, I think so: [root at dc1 ~]# ls -la /lib64/*winb* lrwxrwxrwx 1 root root 40 Jul 23 2013 /lib64/libnss_winbind.so -> /usr/local/samba/lib/libnss_winbind.so.2 lrwxrwxrwx 1 root root 17 Jul 24 2013 /lib64/libnss_winbind.so.2 -> libnss_winbind.so lrwxrwxrwx 1 root root 22 Jun 2 2014 /lib64/libwinbind-client.so -> libwinbind-client.so.0 lrwxrwxrwx 1 root root 49 Jun 2 2014 /lib64/libwinbind-client.so.0 -> /usr/local/samba/lib/private/libwinbind-client.so> If you run 'getent passwd adomainuser' , does it print anything ?Yep - works fine (but returns rfc2307 uid when working i.e. at first; 3000007 when not, i.e. after some time). I get the same result if I run 'getent -s winbind passwd adomainuser'> if you run the command on the other DC, do you get the same result ?Nope - sadly (!) this one works fine, it always returns the rfc2307 values. It's the same version of samba, obviously in the same domain with the same users, but I *think* the relevant difference with this other DC is that nobody actually logs into it or accesses it for files etc.> The 3000007 ID number you refer to, is an xidNumber from idmap.ldb and is > created by samba. Nothing else as far as I am aware will alter idmap.ldb, > though there are a couple of files you can check for: > > gencache_notrans.tdb > gencache.tdb > > If they exist, delete them and then restart samba, do this on both DCsThanks - useful info. I did presume that the 3000007 number was created by samba; I just don't know why it's doing it, as the user definitely has rfc2307 attributes (and indeed works fine via winbind for a short period of time..!) :-( Cheers, Jonathan -- "If we knew what it was we were doing, it would not be called research, would it?" - Albert Einstein
On 11 June 2015 at 23:18, buhorojo <buhorojo.lcb at gmail.com> wrote:> The idmap db will only be consulted if the object does not have either a > uidNumber or gidNumber attribute. The easiest way to stop the pain is to: > 1. make sure that your users have the two attributes > 2. remove the idmap line in smb.conf > 3. kill winbindd > 4. consult nss information directly from your unique ad database using sssdThank you. I wish I could use sssd - unfortunately it no longer starts up now I'm using rfc2307 and have "ldap_id_mapping = False" in sssd.conf (I've asked on the sssd mailing list what's up with that...) I wish I could just use algorithmic RID mapping on a DC, instead of needing to add rfc2307 attributes to all my users, argh! Thanks :) J -- "If we knew what it was we were doing, it would not be called research, would it?" - Albert Einstein