Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

[Samba] Samba 4, Winbind & RFC2307

1,270 views
Skip to first unread message

Thomas Simmons

unread,
Dec 15, 2012, 10:20:01 PM12/15/12
to
Hello,

After provisioning a domain (with rfc2307 attributes), what are the next
steps to enable S4 winbind to use these attributes?

I have one server configured to get user info from AD via LDAP, and with
the proper mappings, getent passwd reports the uid, gid, shell, etc that I
have specified in AD. However, when using winbind for authentication,
getent passwd reports incorrect (generated?) info for these attributes.
I've tried adding:

idmap config DOMAIN:backend = ad
idmap config DOMAIN:schema_mode = rfc2307

and several other 'idmap config DOMAIN' and 'winbind xxx' options to no
avail. Can anyone provide suggestions on how to get this working? Thank you.
--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/options/samba

TAKAHASHI Motonobu

unread,
Dec 16, 2012, 10:00:02 AM12/16/12
to
From: Thomas Simmons <tws...@gmail.com>
Date: Sat, 15 Dec 2012 22:11:00 -0500

> After provisioning a domain (with rfc2307 attributes), what are the next
> steps to enable S4 winbind to use these attributes?

As far as I know, winbind on S4 DC cannot use this attribute. This setting
affects only S4 domain member.

You may manually set these attributes on S4 DC with the script:
http://lists.samba.org/archive/samba-technical/2012-November/089119.html

---
TAKAHASHI Motonobu <mo...@monyo.com>

Thomas Simmons

unread,
Dec 16, 2012, 12:30:03 PM12/16/12
to
Hello Takahashi,

I am using ADUC to manage UNIX attributes and have created the attributes
for each test user.

Just to make sure I understand you correctly; you're saying there is no way
to have S4 winbind use rfc2307 attributes for *nix authentication on a DC,
but it will work on a member server? This is a "clean" provision test setup
that I am running at home. In production (and testing at work) I will be
performing a classicupgrade. I have 300+ users with existing accounts
spread out across many servers. S3 (or it's LDAP backend) is used for auth
& auth on all of our services, so I need to ensure these attributes stay
the same. Worst case I can use NSS+LDAP, but I would prefer to use winbind
if possible.

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

Andrew Bartlett

unread,
Dec 16, 2012, 4:10:01 PM12/16/12
to
On the DC, set:

idmap_ldb:use rfc2307=yes

We realise that having the different behaviour between the DC and the
member server is very annoying, but we have not had the resources to
rework this area of the codebase quite yet.

Andrew Bartlett

--
Andrew Bartlett http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org

Thomas Simmons

unread,
Dec 16, 2012, 5:00:01 PM12/16/12
to
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. 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.

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?

Thank you for your help!

Andrew Bartlett

unread,
Dec 16, 2012, 5:10:02 PM12/16/12
to
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.

Thomas Simmons

unread,
Dec 16, 2012, 5:40:02 PM12/16/12
to
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

Thomas Simmons

unread,
Dec 16, 2012, 5:40:02 PM12/16/12
to
acl:search = false is commented out there, but the behavior is the same
either way.

Thomas Simmons

unread,
Dec 16, 2012, 8:40:02 PM12/16/12
to
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.

Thomas Simmons

unread,
Dec 17, 2012, 8:50:02 AM12/17/12
to
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
--------- -------

Thomas Simmons

unread,
Dec 17, 2012, 10:40:02 AM12/17/12
to
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.

Thomas Simmons

unread,
Dec 17, 2012, 11:30:02 AM12/17/12
to
I got 3.6.10 working!

I had to recompile with:

--with-shared-modules=idmap_ad

Thomas Simmons

unread,
Dec 17, 2012, 2:10:02 PM12/17/12
to
After recompiling --with-shared-modules=idmap_ad, my S4 member also works.
It made no difference on the DC.

"Dr. Hansjörg Maurer"

unread,
Dec 23, 2012, 8:50:01 AM12/23/12
to
Hi

Am 16.12.2012 23:06, schrieb Andrew Bartlett:
> 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 :-(

I got it working with 4.0.0 with some manual interaction
Steps to reproduce:
- add a user to a domain provisioned with --use-rfc2307
samba-tool user add testuser
- add a group testgroup to the domain
- set unix attributes with MMC for user and group
- put user into windows group using MMC and assign testgroup as windows
primary group (not under unix attributes)
- set idmap_ldb:use rfc2307=Yes in smb.conf

Like reported before, the user and the group did not show up in getent
passwd and getent group with the uid and gid set in MMC but with a
random number

testgroup:*:3000022:

S4HJ\testuser:*:3000013:100::/home/testuser:/bin/bash



If I do a

ldbedit -e vi -H /etc/samba/sam.ldb

and manually add
objectClass: posixGroup
to testgroup
and
objectClass: posixAccount
to testuser

it works fine
[root@merlot samba-4.0.0]# getent passwd testuser
S4HJ\testuser:*:10000:10001::/home/testuser:/bin/bash
[root@merlot samba-4.0.0]# getent group testgroup
testgroup:*:10000:
[root@merlot samba-4.0.0]# id -a S4HJ\\testuser
uid=10000(S4HJ\testuser) gid=10001(testgroup2)
Gruppen=10001(testgroup2),100(users),10000(testgroup)

Is ther a way to add this objectclass automatically?

Regards

Hansjörg



--
Dr. Hansjörg Maurer
itsystems Deutschland AG
Linprunstraße 10
80335 München
Tel: +49-89-52 04 68-41
Fax: +49-89-52 04 68-59
E-Mail: hansjoer...@itsd.de
Web: http://www.itsd.de


Amtsgericht München HRB 132146
USt-IdNr. DE 812991301
Steuer-Nr. 143/100/81575

Aufsichtsratsvorsitzender:
Stefan Adam
Vorstand:
Dr. Michael Krocka
Dr. Hansjörg Maurer

Andrew Bartlett

unread,
Dec 23, 2012, 3:30:01 PM12/23/12
to

Please file a bug, so it isn't lost over the Christmas season, but
clearly I need to change the code not to rely on posixAccount and
posixGroup. The steps you performed are reasonable, and while we can
improve our tool to add that objectClass, if AD isn't adding it using
the standard GUI tools, we shouldn't require it either.

Andrew Bartlett

--
Andrew Bartlett http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org

"Dr. Hansjörg Maurer"

unread,
Dec 24, 2012, 2:10:01 AM12/24/12
to
Hi Andrew

Please file a bug, so it isn't lost over the Christmas season, but
clearly I need to change the code not to rely on posixAccount and
posixGroup. The steps you performed are reasonable, and while we can
improve our tool to add that objectClass, if AD isn't adding it using
the standard GUI tools, we shouldn't require it either.

done

https://bugzilla.samba.org/show_bug.cgi?id=9520

Thank you very much

Regrads

Hansjörg

>
> Andrew Bartlett
>


--
Dr. Hansjörg Maurer
itsystems Deutschland AG
Linprunstraße 10
80335 München
Tel: +49-89-52 04 68-41
Fax: +49-89-52 04 68-59
E-Mail: hansjoer...@itsd.de
Web: http://www.itsd.de


Amtsgericht München HRB 132146
USt-IdNr. DE 812991301
Steuer-Nr. 143/100/81575

Aufsichtsratsvorsitzender:
Stefan Adam
Vorstand:
Dr. Michael Krocka
Dr. Hansjörg Maurer

Andrew Bartlett

unread,
Dec 26, 2012, 5:00:01 AM12/26/12
to
On Mon, 2012-12-24 at 08:06 +0100, "Dr. Hansjörg Maurer" wrote:
> Hi Andrew
>
> Please file a bug, so it isn't lost over the Christmas season, but
> clearly I need to change the code not to rely on posixAccount and
> posixGroup. The steps you performed are reasonable, and while we can
> improve our tool to add that objectClass, if AD isn't adding it using
> the standard GUI tools, we shouldn't require it either.
>
> done
>
> https://bugzilla.samba.org/show_bug.cgi?id=9520

Attached is an interim patch. Before we get this into master, I need to
write a series of tests, because having this code untested is just
causing us trouble.

However, the attached should work, and so I would appreciate some
testing if you have time.

Thanks,
0001-s4-idmap-Remove-requirement-that-posixAccount-or-pos.patch

"Dr. Hansjörg Maurer"

unread,
Dec 26, 2012, 3:20:02 PM12/26/12
to
Hi Andrew


Am 26.12.2012 10:54, schrieb Andrew Bartlett:
>
> Attached is an interim patch. Before we get this into master, I need to
> write a series of tests, because having this code untested is just
> causing us trouble.
>
> However, the attached should work, and so I would appreciate some
> testing if you have time.
unfortunately your patch did not solve the problem.
I found a second appearance of posixAccount and posixGroup in idmap.c
and removed it
and after that it works

Here the diff:
[root@merlot winbind]# diff idmap.c idmap.c_org
440c440,441
< "(|(uidNumber=*)(gidNumber=*)))",
---
> "(|(uidNumber=*)(gidNumber=*))"
>
"(|(objectClass=posixAccount)(objectClass=posixGroup)))",

I have no knowledge in "c" and no idea of the logic of the code, so
just take that as feedback and not
as a solution.

Regards

Hansjörg



>
> Thanks,
>
> Andrew Bartlett
>
>
>
> This body part will be downloaded on demand.

Andrew Bartlett

unread,
Dec 26, 2012, 4:20:02 PM12/26/12
to
On Wed, 2012-12-26 at 21:18 +0100, "Dr. Hansjörg Maurer" wrote:
> Hi Andrew
>
>
> Am 26.12.2012 10:54, schrieb Andrew Bartlett:
> >
> > Attached is an interim patch. Before we get this into master, I need to
> > write a series of tests, because having this code untested is just
> > causing us trouble.
> >
> > However, the attached should work, and so I would appreciate some
> > testing if you have time.
> unfortunately your patch did not solve the problem.
> I found a second appearance of posixAccount and posixGroup in idmap.c
> and removed it
> and after that it works

Thanks!

Once I get some tests in, I'll propose this again, but at least now we
have a solution for you.
0001-s4-idmap-Remove-requirement-that-posixAccount-or-pos.patch
0 new messages