Hello again,
I'm getting close to a working setup but still run into glitches here and
there.
I have 2 Ubuntu servers working as AD server, one Ubuntu desktop with
winbind configured. I've setup a number of accounts with Unix
properties. I've been primarily testing with my own account which works
just fine. I've now assigned Unix properties to another account. When I
run 'wbinfo -i' on the AD server I see the correct info:
root at dc1:~# wbinfo -i test
OFFICE\test:*:10000:500:test:/home/OFFICE/test:/bin/false
When I try the same thing on the client I get:
root at testpc2:~# wbinfo -i test
test:*:4294967295:4294967295::/home/test:/bin/bash
I also tried some other accounts and got the same result. The only account
that seems to work fine is my own account (and no it is not in /etc/passwd
:-)
Any idea what might be wrong?
smb.conf on the client:
[global]
security = ADS
workgroup = OFFICE
realm = WIN.OFFICE
log file = /var/log/samba/%m.log
log level = 1
dedicated keytab file = /etc/krb5.keytab
kerberos method = secrets and keytab
winbind refresh tickets = yes
winbind trusted domains only = no
winbind use default domain = yes
winbind enum users = yes
winbind enum groups = yes
winbind offline logon = yes
client signing = yes
client use spnego = yes
idmap config = ad
winbind nss info = rfc2307
# Default idmap config used for BUILTIN and local accounts/groups
idmap backend = tdb
idmap range = 100-499
# idmap config for domain OFFICE
idmap config OFFICE : backend = ad
idmap config OFFICE : schema_mode = rfc2307
idmap config OFFICE : range = 500-29999
It worked for the user with uid 1048, it doesn't work for uid 1059, 1000,
9999, 10000
--
Nico De Ranter
Operations Engineer
T. +32 16 40 12 82
M. +32 497 91 53 78
<http://www.esaturnus.com>
<http://www.esaturnus.com>
<http://www.esaturnus.com/company/news/313>
<http://www.esaturnus.com/>
I expect the difference comes from the fact you are using ID mapping because, according to what I believe I understood, ID map generates UID (the map) and gives these generated UID to users. So one system give one UID to your teset users, another system gives him another UID. You can configure into AD uidNumber and gidNumber to give your AD users definitive UID/GID. Adding that information to AD is not enough as on UNIX/Linux system you use something to build users using information grab in AD. So you have to use a tool which will use GIDs and UIDs you defined in AD. According to my own opinion Winbind is meant to build UNIX system users for Samba file sharing as Winbind rely mostly on MS Windows stuff to build users. This has sense: Samba host files for Windows systems, ACLs must be consistent, so on Samba file servers AD users should be built using MS information from AD. To use AD as a database to build UNIX/Linux systems users you should have a look on SSSD or nslcd, they are more flexible, more designed to build UNIX users from AD. Cheers, mathias 2015-12-07 13:52 GMT+01:00 Nico De Ranter <nico.deranter at esaturnus.com>:> Hello again, > > I'm getting close to a working setup but still run into glitches here and > there. > > I have 2 Ubuntu servers working as AD server, one Ubuntu desktop with > winbind configured. I've setup a number of accounts with Unix > properties. I've been primarily testing with my own account which works > just fine. I've now assigned Unix properties to another account. When I > run 'wbinfo -i' on the AD server I see the correct info: > > root at dc1:~# wbinfo -i test > OFFICE\test:*:10000:500:test:/home/OFFICE/test:/bin/false > > When I try the same thing on the client I get: > > root at testpc2:~# wbinfo -i test > test:*:4294967295:4294967295::/home/test:/bin/bash > > I also tried some other accounts and got the same result. The only account > that seems to work fine is my own account (and no it is not in /etc/passwd > :-) > > Any idea what might be wrong? > > smb.conf on the client: > > [global] > security = ADS > workgroup = OFFICE > realm = WIN.OFFICE > > log file = /var/log/samba/%m.log > log level = 1 > > dedicated keytab file = /etc/krb5.keytab > kerberos method = secrets and keytab > > winbind refresh tickets = yes > winbind trusted domains only = no > winbind use default domain = yes > winbind enum users = yes > winbind enum groups = yes > winbind offline logon = yes > > client signing = yes > client use spnego = yes > > idmap config = ad > winbind nss info = rfc2307 > > # Default idmap config used for BUILTIN and local accounts/groups > idmap backend = tdb > idmap range = 100-499 > > # idmap config for domain OFFICE > idmap config OFFICE : backend = ad > idmap config OFFICE : schema_mode = rfc2307 > idmap config OFFICE : range = 500-29999 > > It worked for the user with uid 1048, it doesn't work for uid 1059, 1000, > 9999, 10000 > > -- > Nico De Ranter > > Operations Engineer > > T. +32 16 40 12 82 > > M. +32 497 91 53 78 > > > <http://www.esaturnus.com> > > > > <http://www.esaturnus.com> > > > > > <http://www.esaturnus.com/company/news/313> > > > > <http://www.esaturnus.com/> > -- > To unsubscribe from this list go to the following URL and read the > instructions: https://lists.samba.org/mailman/options/samba >
I am using rfc2307 unix properties in AD. So I would expect winbind to use the uid and gid from rfc2307. Hmm, I just noticed that 'wbinfo -i test' actually gives me different results on my first AD, second AD and client. Only the first AD shows the result that I'm actually expecting. Somehow the others are ignoring the rfc2307 info. Nico On Mon, Dec 7, 2015 at 2:10 PM, mathias dufresne <infractory at gmail.com> wrote:> I expect the difference comes from the fact you are using ID mapping > because, according to what I believe I understood, ID map generates UID > (the map) and gives these generated UID to users. So one system give one > UID to your teset users, another system gives him another UID. > > You can configure into AD uidNumber and gidNumber to give your AD users > definitive UID/GID. > Adding that information to AD is not enough as on UNIX/Linux system you use > something to build users using information grab in AD. So you have to use a > tool which will use GIDs and UIDs you defined in AD. > > According to my own opinion Winbind is meant to build UNIX system users for > Samba file sharing as Winbind rely mostly on MS Windows stuff to build > users. This has sense: Samba host files for Windows systems, ACLs must be > consistent, so on Samba file servers AD users should be built using MS > information from AD. > > To use AD as a database to build UNIX/Linux systems users you should have a > look on SSSD or nslcd, they are more flexible, more designed to build UNIX > users from AD. > > Cheers, > > mathias > > 2015-12-07 13:52 GMT+01:00 Nico De Ranter <nico.deranter at esaturnus.com>: > > > Hello again, > > > > I'm getting close to a working setup but still run into glitches here and > > there. > > > > I have 2 Ubuntu servers working as AD server, one Ubuntu desktop with > > winbind configured. I've setup a number of accounts with Unix > > properties. I've been primarily testing with my own account which works > > just fine. I've now assigned Unix properties to another account. When I > > run 'wbinfo -i' on the AD server I see the correct info: > > > > root at dc1:~# wbinfo -i test > > OFFICE\test:*:10000:500:test:/home/OFFICE/test:/bin/false > > > > When I try the same thing on the client I get: > > > > root at testpc2:~# wbinfo -i test > > test:*:4294967295:4294967295::/home/test:/bin/bash > > > > I also tried some other accounts and got the same result. The only > account > > that seems to work fine is my own account (and no it is not in > /etc/passwd > > :-) > > > > Any idea what might be wrong? > > > > smb.conf on the client: > > > > [global] > > security = ADS > > workgroup = OFFICE > > realm = WIN.OFFICE > > > > log file = /var/log/samba/%m.log > > log level = 1 > > > > dedicated keytab file = /etc/krb5.keytab > > kerberos method = secrets and keytab > > > > winbind refresh tickets = yes > > winbind trusted domains only = no > > winbind use default domain = yes > > winbind enum users = yes > > winbind enum groups = yes > > winbind offline logon = yes > > > > client signing = yes > > client use spnego = yes > > > > idmap config = ad > > winbind nss info = rfc2307 > > > > # Default idmap config used for BUILTIN and local accounts/groups > > idmap backend = tdb > > idmap range = 100-499 > > > > # idmap config for domain OFFICE > > idmap config OFFICE : backend = ad > > idmap config OFFICE : schema_mode = rfc2307 > > idmap config OFFICE : range = 500-29999 > > > > It worked for the user with uid 1048, it doesn't work for uid 1059, 1000, > > 9999, 10000 > > > > >-- Nico De Ranter Operations Engineer T. +32 16 40 12 82 M. +32 497 91 53 78 <http://www.esaturnus.com> <http://www.esaturnus.com> <http://www.esaturnus.com/company/news/313> <http://www.esaturnus.com/>
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 There is one parameter in your smb.conf missing: idmap config * : range 1000000-1999999 Or any other range other then the range of your Domain OFFICE Then you should do a "net cache flush" or better restart your samba-daemon. Am 07.12.15 um 13:52 schrieb Nico De Ranter:> Hello again, > > I'm getting close to a working setup but still run into glitches > here and there. > > I have 2 Ubuntu servers working as AD server, one Ubuntu desktop > with winbind configured. I've setup a number of accounts with > Unix properties. I've been primarily testing with my own account > which works just fine. I've now assigned Unix properties to > another account. When I run 'wbinfo -i' on the AD server I see the > correct info: > > root at dc1:~# wbinfo -i test > OFFICE\test:*:10000:500:test:/home/OFFICE/test:/bin/false > > When I try the same thing on the client I get: > > root at testpc2:~# wbinfo -i test > test:*:4294967295:4294967295::/home/test:/bin/bash > > I also tried some other accounts and got the same result. The > only account that seems to work fine is my own account (and no it > is not in /etc/passwd :-) > > Any idea what might be wrong? > > smb.conf on the client: > > [global] security = ADS workgroup = OFFICE realm = WIN.OFFICE > > log file = /var/log/samba/%m.log log level = 1 > > dedicated keytab file = /etc/krb5.keytab kerberos method = secrets > and keytab > > winbind refresh tickets = yes winbind trusted domains only = no > winbind use default domain = yes winbind enum users = yes winbind > enum groups = yes winbind offline logon = yes > > client signing = yes client use spnego = yes > > idmap config = ad winbind nss info = rfc2307 > > # Default idmap config used for BUILTIN and local accounts/groups > idmap backend = tdb idmap range = 100-499 > > # idmap config for domain OFFICE idmap config OFFICE : backend = ad > idmap config OFFICE : schema_mode = rfc2307 idmap config OFFICE : > range = 500-29999 > > It worked for the user with uid 1048, it doesn't work for uid > 1059, 1000, 9999, 10000 >-----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.16 (Darwin) iEYEARECAAYFAlZloIUACgkQ2JOGcNAHDTbAWgCcDdpPfgI+z5OonQc9Xh71yU75 WbkAn2WN3zj2o1TmZSTFSemN/QmbNQqF =Jlvw -----END PGP SIGNATURE-----
On 07/12/15 12:52, Nico De Ranter wrote:> Hello again, > > I'm getting close to a working setup but still run into glitches here and > there. > > I have 2 Ubuntu servers working as AD server, one Ubuntu desktop with > winbind configured. I've setup a number of accounts with Unix > properties. I've been primarily testing with my own account which works > just fine. I've now assigned Unix properties to another account. When I > run 'wbinfo -i' on the AD server I see the correct info: > > root at dc1:~# wbinfo -i test > OFFICE\test:*:10000:500:test:/home/OFFICE/test:/bin/false > > When I try the same thing on the client I get: > > root at testpc2:~# wbinfo -i test > test:*:4294967295:4294967295::/home/test:/bin/bash > > I also tried some other accounts and got the same result. The only account > that seems to work fine is my own account (and no it is not in /etc/passwd > :-) > > Any idea what might be wrong? > > smb.conf on the client: > > [global] > security = ADS > workgroup = OFFICE > realm = WIN.OFFICE > > log file = /var/log/samba/%m.log > log level = 1 > > dedicated keytab file = /etc/krb5.keytab > kerberos method = secrets and keytab > > winbind refresh tickets = yes > winbind trusted domains only = no > winbind use default domain = yes > winbind enum users = yes > winbind enum groups = yes > winbind offline logon = yes > > client signing = yes > client use spnego = yes > > idmap config = ad > winbind nss info = rfc2307 > > # Default idmap config used for BUILTIN and local accounts/groups > idmap backend = tdb > idmap range = 100-499 > > # idmap config for domain OFFICE > idmap config OFFICE : backend = ad > idmap config OFFICE : schema_mode = rfc2307 > idmap config OFFICE : range = 500-29999Your 'idmap config' block really should look like this: idmap config *:backend = tdb idmap config *:range = 2000-9999 idmap config SAMDOM:backend = ad idmap config SAMDOM:schema_mode = rfc2307 idmap config SAMDOM:range = 10000-99999 Also why are you using such strange ID numbers? Rowland> It worked for the user with uid 1048, it doesn't work for uid 1059, 1000, > 9999, 10000 >
I'm coming from a Debian system so my system accounts are below 1000, regular accounts start at 1000. For some historical reason somebody gave our main group id 500 so therefor I want my usable range to start at 500. Do I need both idmap config *:range and idmap config SAMDOM:range? I also tried with only 'idmap config *:range' but that didn't seem to help. I'll try again tomorrow. I also noticed that my second AD didn't have rfc2307 enabled so that may also have introduced some issues. @Stefan Kania, thanks for the 'net cache flush', I didn't know that. Nico On Mon, Dec 7, 2015 at 4:27 PM, Rowland penny <rpenny at samba.org> wrote:> On 07/12/15 12:52, Nico De Ranter wrote: > >> Hello again, >> >> I'm getting close to a working setup but still run into glitches here and >> there. >> >> I have 2 Ubuntu servers working as AD server, one Ubuntu desktop with >> winbind configured. I've setup a number of accounts with Unix >> properties. I've been primarily testing with my own account which works >> just fine. I've now assigned Unix properties to another account. When I >> run 'wbinfo -i' on the AD server I see the correct info: >> >> root at dc1:~# wbinfo -i test >> OFFICE\test:*:10000:500:test:/home/OFFICE/test:/bin/false >> >> When I try the same thing on the client I get: >> >> root at testpc2:~# wbinfo -i test >> test:*:4294967295:4294967295::/home/test:/bin/bash >> >> I also tried some other accounts and got the same result. The only >> account >> that seems to work fine is my own account (and no it is not in /etc/passwd >> :-) >> >> Any idea what might be wrong? >> >> smb.conf on the client: >> >> [global] >> security = ADS >> workgroup = OFFICE >> realm = WIN.OFFICE >> >> log file = /var/log/samba/%m.log >> log level = 1 >> >> dedicated keytab file = /etc/krb5.keytab >> kerberos method = secrets and keytab >> >> winbind refresh tickets = yes >> winbind trusted domains only = no >> winbind use default domain = yes >> winbind enum users = yes >> winbind enum groups = yes >> winbind offline logon = yes >> >> client signing = yes >> client use spnego = yes >> >> idmap config = ad >> winbind nss info = rfc2307 >> >> # Default idmap config used for BUILTIN and local accounts/groups >> idmap backend = tdb >> idmap range = 100-499 >> >> # idmap config for domain OFFICE >> idmap config OFFICE : backend = ad >> idmap config OFFICE : schema_mode = rfc2307 >> idmap config OFFICE : range = 500-29999 >> > > Your 'idmap config' block really should look like this: > > idmap config *:backend = tdb > idmap config *:range = 2000-9999 > idmap config SAMDOM:backend = ad > idmap config SAMDOM:schema_mode = rfc2307 > idmap config SAMDOM:range = 10000-99999 > > Also why are you using such strange ID numbers? > > Rowland > > It worked for the user with uid 1048, it doesn't work for uid 1059, 1000, >> 9999, 10000 >> >> > > -- > To unsubscribe from this list go to the following URL and read the > instructions: https://lists.samba.org/mailman/options/samba >-- Nico De Ranter Operations Engineer T. +32 16 40 12 82 M. +32 497 91 53 78 <http://www.esaturnus.com> <http://www.esaturnus.com> <http://www.esaturnus.com/company/news/313> <http://www.esaturnus.com/>