Re: [Samba] winbind: uid range is ignored

[Jonathan Buzzard]

On 02/08/12 16:01, steve wrote:
> Hi everone.
>
> Ubuntu 12.04 v3.6 clients with winbind joined to 12.04 Samba4 DC
>
> Clients:
> smb.conf
> [global]
> realm = polop.site
> workgroup = POLOP
> security = ADS
> wide links = Yes
> unix extensions = No
> template shell = /bin/bash
> winbind enum users = Yes
> winbind enum groups = Yes
> idmap uid = 300000-400000
> idmap gid = 20000-30000
>
> /etc/nsswitch.conf
> passwd: compat winbind
> group: compat winbind
>
> Problem:
> The uid range is ignored. Both uid and gid come from the gid range. e.g.:
> getent passwd steve2
> POLOP\steve2:*:20007:20000:steve2:/home/POLOP/steve2:/bin/bash
>
> Why is the uid range of 300000-400000 ignored?

I have a feeling that there is no separate uid and gid range in 3.6.
Check the man page.

JAB.

--
Jonathan A. Buzzard Email: jonathan (at) buzzard.me.uk
Fife, United Kingdom.
--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/options/samba

[steve]

Hi everone.

Ubuntu 12.04 v3.6 clients with winbind joined to 12.04 Samba4 DC

Clients:
smb.conf
[global]
realm = polop.site
workgroup = POLOP
security = ADS
wide links = Yes
unix extensions = No
template shell = /bin/bash
winbind enum users = Yes
winbind enum groups = Yes
idmap uid = 300000-400000
idmap gid = 20000-30000

/etc/nsswitch.conf
passwd: compat winbind
group: compat winbind

Problem:
The uid range is ignored. Both uid and gid come from the gid range. e.g.:
getent passwd steve2
POLOP\steve2:*:20007:20000:steve2:/home/POLOP/steve2:/bin/bash

Why is the uid range of 300000-400000 ignored?

Cheers,
Steve

[Bjoern Baumbach]

Hi Steve,

please use "idmap config * : range = ..." instead of idmap uid/gid.

Best regards
Björn

SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen
phone: +49-551-370000-0, fax: +49-551-370000-9
AG Göttingen, HRB 2816, GF: Dr. Johannes Loxen
http://www.sernet.de, mailto:kon...@sernet.de

[steve]

On 02/08/12 17:14, Bjoern Baumbach wrote:
> Hi Steve,
>
> please use "idmap config * : range = ..." instead of idmap uid/gid.
>

Thanks Jonathan and Bjoern
I have that now.

I chose:
idmap config * : range = 30000-40000

I have deleted the winbind files from /var/lib/samba and
/var/cache/samba and restarted smbd and winbind but the idmap ranges are
still at the old values. In fact they are the same numerical values as
on the DC e.g.

-rw-r--r-- 1 3000037 20513 0 Aug 2 17:34 file1

Back on the DC/fileserver that is correctly mapped as:

-rw-r--r-- 1 POLOP\steve2 Domain Users 0 Aug 2 17:34 file1

Is there a cache somewhere else? I have even totally purged the whole of
samba and reinstalled from nothing but still the old values reappear.
How do I lose the old values so it accepts my new range and maps the
files correctly as humanly readable uid:gid pairs rather than numbers?
nscd is not active.

cheers
Steve

/etc/samba/smb.conf

[global]
realm = polop.site
workgroup = POLOP
security = ADS
wide links = Yes
unix extensions = No
template shell = /bin/bash
winbind enum users = Yes
winbind enum groups = Yes

idmap config * : backend = tdb
idmap config * : range = 30000-40000

[Gémes Géza]

I would suggest using idmap_ad:

http://www.samba.org/samba/docs/man/manpages-3/idmap_ad.8.html

Regards

Geza Gemes

[steve]

Hi Geza
No. In this case it is a pure-by-the-book winbind test lan.

The problem is this:

Here is my id:
POLOP\steve2@ubuntu1:~$ id
uid=30007(POLOP\steve2) gid=30014(POLOP\domain users)
groups=30014(POLOP\domain users),30016(POLOP\staff),30018(BUILTIN\users)

When I create a file, I want to see a uid:gid of POLOP\steve2
POLOP\domain users (as indeed I do back on the fileserver/DC)

But on the client, I see only the uid:gid _numbers_ which are stored in
idmap.ldb on the server:

POLOP\steve2@ubuntu1:~$ touch afile
POLOP\steve2@ubuntu1:~$ ls -l afile
-rw-r--r-- 1 3000037 20513 0 Aug 2 18:34 afile

How do I convert
3000037 to POLOP\steve2
and
20513 to POLOP\domain users
on the client?

The shares are mounted via kerberized nfs on the client and _did_ map
correctly before this thread started.

Cheers,
Steve

[NdK]

Il 02/08/2012 18:42, steve ha scritto:

> The shares are mounted via kerberized nfs on the client and _did_ map
> correctly before this thread started.

Are you sure you updated /etc/nnsswitch.conf to use winbind after
purging the old Samba install?

BYtE,
Diego.

[steve]

On 02/08/12 20:57, NdK wrote:
> Il 02/08/2012 18:42, steve ha scritto:
>
>> The shares are mounted via kerberized nfs on the client and _did_ map
>> correctly before this thread started.
> Are you sure you updated /etc/nnsswitch.conf to use winbind after
> purging the old Samba install?
>
> BYtE,
> Diego.
>

Hi
Yes, I have

passwd: files winbind
group: files winbind

getent passwd/group works fine. I get the names and coresponding uid:gid
numbers within the range specified in smb.conf but all I get when I list
files on the nfs share, are numerical uid:gid values. I want those
values to be DOMAIN\username DOMAIN\group rather than numerical values.

How do I do that?

The uid:gid values are not in the range set in smb.conf. They are the
uid:gid values in idmap _on the server_. Its as if nsswitch is ignoring
winbind.


Cheers,
Steve

[NdK]

Il 03/08/2012 08:01, steve ha scritto:

> getent passwd/group works fine. I get the names and coresponding uid:gid
> numbers within the range specified in smb.conf but all I get when I list
> files on the nfs share, are numerical uid:gid values. I want those
> values to be DOMAIN\username DOMAIN\group rather than numerical values.
>
> How do I do that?

Use *the same* range on both server and clients.

> The uid:gid values are not in the range set in smb.conf. They are the
> uid:gid values in idmap _on the server_. Its as if nsswitch is ignoring
> winbind.

Obvious. NFS passes *numeric* IDs, so if a file is owned by userid
123456 on the server, then the client will see the same 123456 uid.
That, if not correctly mapped, would give another user access to it
(negating access to the original one).

Actually, as long as you only allow NFS access to the server, it's
enough that all clients use the same mapping (the server could know
nothing about samba, winbind, ad and so on). But you'll need trusted
clients (ever wondered why 'client' contains 'lie'? ).

BYtE,
Diego.

[steve]

On 03/08/12 09:01, NdK wrote:
> Il 03/08/2012 08:01, steve ha scritto:
>
>> getent passwd/group works fine. I get the names and coresponding uid:gid
>> numbers within the range specified in smb.conf but all I get when I list
>> files on the nfs share, are numerical uid:gid values. I want those
>> values to be DOMAIN\username DOMAIN\group rather than numerical values.
>>
>> How do I do that?
> Use *the same* range on both server and clients.

Hi Diego
Thanks for your patience in helping me sort this.

It doesn't seem to matter. I can have the same id range on both server
and client. What is uid 3000027 on the server becomes uid 3000002 on the
client.

>
>> The uid:gid values are not in the range set in smb.conf. They are the
>> uid:gid values in idmap _on the server_. Its as if nsswitch is ignoring
>> winbind.
> Obvious. NFS passes *numeric* IDs, so if a file is owned by userid
> 123456 on the server, then the client will see the same 123456 uid.
> That, if not correctly mapped, would give another user access to it
> (negating access to the original one).

That's exactly my point. My 3000027 maps correctly to DOMAIN\steve2 on
the server but getent passwd on the client gives DOMAIN\steve2 as
3000002. If steve2 logs in and creates a file it becomes uid 3000027 and
_not_ 3000002. If winbind is doing the mapping correctly it should map
3000027 to 3000002 and when I list a file that I have made it should
give me back a uid of DOMAIN\steve2. It doesn't. The file created has
uid 3000027 which works _but_ I want to see uid's as names, not numbers.

I've also tried adding posixAccount, uidNumber and gidNumber to pull the
uid:gid directly from AD with:
idmap config * : backend = ad
but then, getent passwd gives me no list of users.

Really stuck on this one. . .
The client is Ubuntu 12.04 with samba 3.6.3. Maybe 3.6.3 has bugs?

Cheers,
steve

[steve]

On 03/08/12 10:22, steve wrote:
> On 03/08/12 09:01, NdK wrote:
>> Il 03/08/2012 08:01, steve ha scritto:
>>

It looks as though it's this:
https://bugzilla.samba.org/show_bug.cgi?id=8676

Ubuntu 12.04 ships with 3.6.3 :-(

[Jonathan Buzzard]

On 03/08/12 07:01, steve wrote:
> On 02/08/12 20:57, NdK wrote:
>> Il 02/08/2012 18:42, steve ha scritto:
>>
>>> The shares are mounted via kerberized nfs on the client and _did_ map
>>> correctly before this thread started.
>> Are you sure you updated /etc/nnsswitch.conf to use winbind after
>> purging the old Samba install?
>>
>> BYtE,
>> Diego.
>>
> Hi
> Yes, I have
>
> passwd: files winbind
> group: files winbind
>
> getent passwd/group works fine. I get the names and coresponding uid:gid
> numbers within the range specified in smb.conf but all I get when I list
> files on the nfs share, are numerical uid:gid values. I want those
> values to be DOMAIN\username DOMAIN\group rather than numerical values.
>
> How do I do that?
>
> The uid:gid values are not in the range set in smb.conf. They are the
> uid:gid values in idmap _on the server_. Its as if nsswitch is ignoring
> winbind.
>

If I get this correctly you have files on an NFS server with UID/GID
values in say range 10000-19999, and have winbind configured to do
mappings in the range of 20000-29999.

Doh, winbind will look at the UID/GID on the NFS server and go outside
the range I am set to map and do nothing because you have told it to do so.

JAB.

--
Jonathan A. Buzzard Email: jonathan (at) buzzard.me.uk
Fife, United Kingdom.

[Gémes Géza]

Please try with

idmap backend = tdb
idmap uid = some uninteresting range
idmap gid = some uninteresting range

idmap config YOURDOMAINNAMEHERE : backend = ad
idmap config YOURDOMAINNAMEHERE : range = the range you want your
uids/gids to be

Like in http://www.samba.org/samba/docs/man/manpages-3/idmap_ad.8.html

Regards

Geza Gemes

[steve]

Thanks again Geza
Am doing a total client reinstall atm, but that looks good.

On the DC, I take it that for a user object I shall need:
objectClass: posixAccount
uidNumber: 123
gidNumber: 456

and for a group object
objectClass: posixGroup
gidNumber: 456

Question:
1. Does the config you give go on both DC and client?
2. confusion:
This:
https://wiki.samba.org/index.php/Samba_3.6_Features_added/changed
says that

idmap uid = some uninteresting range
idmap gid = some uninteresting range

has been replaced by:
idmap config YOURDOMAINNAMEHERE : range= the range you want your
uids/gids to be
Should I remove the:

idmap uid = some uninteresting range
idmap gid = some uninteresting range

My gidNumbers start at 20513 (Domain Users) and my last uidNumber is
currenlty 3000157 so how about:
idmap config YOURDOMAINNAMEHERE : range=20000-4000000
?
3. If uidNumber and gidNumber are pulled from AD, why do I need to
specify a range?

Cheers,
Steve

[steve]

On 03/08/12 13:07, NdK wrote:

> Il 03/08/2012 10:22, steve ha scritto:
>
>> It doesn't seem to matter. I can have the same id range on both server
>> and client. What is uid 3000027 on the server becomes uid 3000002 on the
>> client.

> Remember to delete all .tdb files and rejoin the machine between tests
> w/ different backends, or you'll get big troubles.
> Since you can control your domain, stick to ad backend. And remember to
> keep uids/gids stored in AD in a "safe" range (less than 500 and ...
> wooops! -- remember 0 is root, that could get squashed to nobody by NFS).
>
> Hope reinstall brings you good news :)
>
> BYtE,
> Diego.
>
Hi Diego
Thanks for the tip. In fact, Samba4 defaults to 300000-400000 which I
think is pretty safe?

My main problem is on the 3.6 client where the ad backend is not
honoured. As you say, I've gone for a reinstall with an openSUSE client
which has a patched 3.6.6 so hoping. . .
Cheers,
Steve

[NdK]

Il 03/08/2012 10:22, steve ha scritto:

> It doesn't seem to matter. I can have the same id range on both server
> and client. What is uid 3000027 on the server becomes uid 3000002 on the
> client.

Remember to delete all .tdb files and rejoin the machine between tests
w/ different backends, or you'll get big troubles.
Since you can control your domain, stick to ad backend. And remember to
keep uids/gids stored in AD in a "safe" range (less than 500 and ...
wooops! -- remember 0 is root, that could get squashed to nobody by NFS).

Hope reinstall brings you good news :)

BYtE,
Diego.

[NdK]

Il 03/08/2012 13:18, steve ha scritto:

> Thanks for the tip. In fact, Samba4 defaults to 300000-400000 which I
> think is pretty safe?

Only for a small domain... In our tree it would be WAY too small (could
contain no more than about 20% of the groups we have in a single domain...).

> My main problem is on the 3.6 client where the ad backend is not
> honoured. As you say, I've gone for a reinstall with an openSUSE client
> which has a patched 3.6.6 so hoping. . .

Might even be that "not honoured" was simply due to caching: you had tdb
backend (that assigns uids/gids sequentially as needed), then switched
to rid, but cache still contained old values from tdb. That's why I told
you to temove *all* .tdb files and rejoin.

BYtE,
Diego.

[steve]

On 03/08/12 13:54, NdK wrote:
> Il 03/08/2012 13:18, steve ha scritto:
>
>> Thanks for the tip. In fact, Samba4 defaults to 300000-400000 which I
>> think is pretty safe?
> Only for a small domain... In our tree it would be WAY too small (could
> contain no more than about 20% of the groups we have in a single domain...).
>
>> My main problem is on the 3.6 client where the ad backend is not
>> honoured. As you say, I've gone for a reinstall with an openSUSE client
>> which has a patched 3.6.6 so hoping. . .
> Might even be that "not honoured" was simply due to caching: you had tdb
> backend (that assigns uids/gids sequentially as needed), then switched
> to rid, but cache still contained old values from tdb. That's why I told
> you to temove *all* .tdb files and rejoin.
>

Hi Diego
That's quite easy in Samba3 but which tdb's must I remove in Samba4? In
fact, how would I rejoin the DC to itself?
Cheers,
steve

[NdK]

Il 03/08/2012 16:21, steve ha scritto:

> That's quite easy in Samba3 but which tdb's must I remove in Samba4? In
> fact, how would I rejoin the DC to itself?

You shouldn't use DCs for anything else other than DC. No file server.
No gateway. *Nothing*. They're a crytical piece of your network
infrastructure and must be as closed as possible.

The NFS server doesn't care about Samba at all: it reveives UIDs adn
GIDs and stores 'em as given. No mapping happens here.

What makes me think you have a *big* misunderstanding about what winbnd
mapping does is this sentence from another message:

> If winbind is doing the mapping correctly it should map 3000027 to
> 3000002

No. Winbind maps back and forth between user *names* (and groups) and
*UIDs* (and GIDs), not between server UIDs and local GIDs ! It doesn't
know if an UID is local or from a server.

So, that means that (given no other kind of access to the NFS server is
allowed) it's enough that all your *clients* use the same mapping
between SIDs and UIDs/GIDs and you're OK. If not, you have a big problem.

You have many ways to obtain that "same mapping" objective. I chose to
use rid 'cause I couldn't modify my AD schema. But the preferred way is
extend AD schema and specify there the UIDs and GIDs.

Hope this helps to clarify.

BYtE,
Diego.

[steve]

On 04/08/12 09:39, NdK wrote:
> Il 03/08/2012 16:21, steve ha scritto:
>
>> That's quite easy in Samba3 but which tdb's must I remove in Samba4? In
>> fact, how would I rejoin the DC to itself?
> You shouldn't use DCs for anything else other than DC. No file server.
> No gateway. *Nothing*. They're a crytical piece of your network
> infrastructure and must be as closed as possible.

Hi Diego. Hi everyone
I'd like to have a separate fileserver running s3fs on another Samba4
installation. Could I do that by installing Samba4 and joining the
domain as a member rather than a DC?

>
> The NFS server doesn't care about Samba at all: it reveives UIDs adn
> GIDs and stores 'em as given. No mapping happens here.
>

Yep. Got that bit

> What makes me think you have a *big* misunderstanding about what winbnd
> mapping does is this sentence from another message:
>> If winbind is doing the mapping correctly it should map 3000027 to
>> 3000002

Yes, I did misunderstand that. I've now adjusted my brain to match:-)

> No. Winbind maps back and forth between user *names* (and groups) and
> *UIDs* (and GIDs), not between server UIDs and local GIDs ! It doesn't
> know if an UID is local or from a server.
>
> So, that means that (given no other kind of access to the NFS server is
> allowed) it's enough that all your *clients* use the same mapping
> between SIDs and UIDs/GIDs and you're OK. If not, you have a big problem.
>
> You have many ways to obtain that "same mapping" objective. I chose to
> use rid 'cause I couldn't modify my AD schema. But the preferred way is
> extend AD schema and specify there the UIDs and GIDs.

You don't have to extend the schema. You can store all the rfc2307
attributes and objects (posixAccount, posixGroup, uidNumber,gidNumber. .
.) in the m$ schema that ships with S4.

>
> Hope this helps to clarify.

Yes it does. Thank you.

My aim is to have:
idmap config : MYDOMAIN : backend = ad
and
idmap config : MYDOMAIN : range = abc-def

recognised and with the uidNumber and gidNumber attributes being pulled
from AD rather than any other mapping. To this end I have a test user
user object with:
objectClass: posixAccount
uidNumber: xyz
gidNumber abc

and a test group object:

objectClass: posixGroup
gidNumber: abc

I assume that with the ad backend both the user and group will come from
AD and not idmap.

Just waiting for the test lan to install and compile a totally new
openSUSE 12.1 with Samba4 and a vBox openSUSE client, also fresh install.

How am I doing?
Cheers,
Steve

[NdK]

Il 04/08/2012 12:00, steve ha scritto:

>> You have many ways to obtain that "same mapping" objective. I chose to
>> use rid 'cause I couldn't modify my AD schema. But the preferred way is
>> extend AD schema and specify there the UIDs and GIDs.
> You don't have to extend the schema. You can store all the rfc2307
> attributes and objects (posixAccount, posixGroup, uidNumber,gidNumber. .
> .) in the m$ schema that ships with S4.

Too bad my AD controllers are M$ W2k3, w/o rfc2307 extension :( That's
why I'm stuck with rid.

> My aim is to have:
> idmap config : MYDOMAIN : backend = ad
> and
> idmap config : MYDOMAIN : range = abc-def
>
> recognised and with the uidNumber and gidNumber attributes being pulled
> from AD rather than any other mapping. To this end I have a test user
> user object with:
> objectClass: posixAccount
> uidNumber: xyz
> gidNumber abc
>
> and a test group object:
>
> objectClass: posixGroup
> gidNumber: abc
>
> I assume that with the ad backend both the user and group will come from
> AD and not idmap.

Well, idmap queries its backend for the mapping.

> Just waiting for the test lan to install and compile a totally new
> openSUSE 12.1 with Samba4 and a vBox openSUSE client, also fresh install.
>
> How am I doing?

Should work at the first try. But someone else that already used S4 and
AD backend can confirm for sure. :)

BYtE,
Diego.

[steve]

On 04/08/12 13:21, NdK wrote:
> Il 04/08/2012 12:00, steve ha scritto:
>
>>> You have many ways to obtain that "same mapping" objective. I chose to
>>> use rid 'cause I couldn't modify my AD schema. But the preferred way is
>>> extend AD schema and specify there the UIDs and GIDs.
>> You don't have to extend the schema. You can store all the rfc2307
>> attributes and objects (posixAccount, posixGroup, uidNumber,gidNumber. .
>> .) in the m$ schema that ships with S4.
> Too bad my AD controllers are M$ W2k3, w/o rfc2307 extension :( That's
> why I'm stuck with rid.
>

Hi Diego.

Ah I see. I didn't mean to offend. I simply assumed you were using
Samba4. I think m$ gave them the 2008 schema as a result of a court
case. That _does_ have rfc2307.

With your and Geza's help I think I'm finally getting somewhere.

>> My aim is to have:
>> idmap config : MYDOMAIN : backend = ad
>> and
>> idmap config : MYDOMAIN : range = abc-def
>>
>> recognised and with the uidNumber and gidNumber attributes being pulled
>> from AD rather than any other mapping. To this end I have a test user
>> user object with:
>> objectClass: posixAccount
>> uidNumber: xyz
>> gidNumber abc
>>
>> and a test group object:
>>
>> objectClass: posixGroup
>> gidNumber: abc
>>
>> I assume that with the ad backend both the user and group will come from
>> AD and not idmap.
> Well, idmap queries its backend for the mapping.
>
>> Just waiting for the test lan to install and compile a totally new
>> openSUSE 12.1 with Samba4 and a vBox openSUSE client, also fresh install.
>>
>> How am I doing?
> Should work at the first try.

Really need this one. I have to compare winbind with nss-ldapd to do
this stuff. Have the latter going fine.

But someone else that already used S4 and
> AD backend can confirm for sure. :)
>

Hope so. There must be someone else out there.

Cheers,
Steve

[NdK]

Il 04/08/2012 13:40, steve ha scritto:

>> Too bad my AD controllers are M$ W2k3, w/o rfc2307 extension :( That's
>> why I'm stuck with rid.

> Ah I see. I didn't mean to offend.

No offense perceived :)

> I simply assumed you were using Samba4.

If only I could...

> I think m$ gave them the 2008 schema as a result of a court
> case. That _does_ have rfc2307.

I don't know the background... I'm just a normal user w/ usually big
troubles. So big that it seems nobody knows the answer :(

>> Should work at the first try.
> Really need this one. I have to compare winbind with nss-ldapd to do
> this stuff. Have the latter going fine.

What you can't do with ldap (IIUC) is nested group membership. W/ AD you
can have it.
Up to you if that's important enough (for me it was: I usually place the
service.admins group into the service.allowed one, so that all admins
are automatically allowed...

BYtE,
Diego

[steve]

On 04/08/12 20:34, NdK wrote:
> Il 04/08/2012 13:40, steve ha scritto:
>
>>> Too bad my AD controllers are M$ W2k3, w/o rfc2307 extension :( That's
>>> why I'm stuck with rid.
>> Ah I see. I didn't mean to offend.
> No offense perceived :)

Hi
That's good to know it wasn't a misunderstanding.

Most of our LAN uses Linux with only a few m$ boxes. The Samba4 LDAP is
excellent compared to openLDAP, so I guess that's our main priority.

What I _do_ have is is fast mapping via nss-pam-ldapd, where everything
just works. All rfc2307 comes from the directory by default. Anything
you like. loginShell, uinixHomeDirectory. . . On a per user or group
basis. Total flexibility.

In comparison, winbind seems overcomplicated and restrictive (and simply
does not work with either Ubuntu nor openSUSE 3.6.3). It also seems very
restricted in that we have turn off unix attributes and use wide links
so we can symlink to the only available folder for unixHomeDirectory.

Anyway, I've not given up yet, but it really does look like winbind is
past it's sell by date;)

Cheers and thanks for your continued support,
Steve

[NdK]

Il 04/08/2012 21:13, steve ha scritto:

> In comparison, winbind seems overcomplicated and restrictive (and simply
> does not work with either Ubuntu nor openSUSE 3.6.3). It also seems very
> restricted in that we have turn off unix attributes and use wide links
> so we can symlink to the only available folder for unixHomeDirectory.

I can tell for sure that it works perfectly in Ubuntu 12.04LTS (IIRC the
exact version) w/ RID backend.
Uh? "wide links" seems a bad idea to me... At least from a security
perspective.
Why a single home directory? We have a single NFS share containing
folders for the two domains and inside those a folder for each home.
We are trying to migrate away from that, preferring a '[homes]' share
where users will place the data they want to have available on every PC.
This way even Firefox should work...

> Anyway, I've not given up yet, but it really does look like winbind is
> past it's sell by date;)

Once you have it working, it's addictive :)

BYtE,
Diego.

[Jonathan Buzzard]

NdK wrote:
> Il 04/08/2012 12:00, steve ha scritto:
>
>>> You have many ways to obtain that "same mapping" objective. I chose to
>>> use rid 'cause I couldn't modify my AD schema. But the preferred way is
>>> extend AD schema and specify there the UIDs and GIDs.
>> You don't have to extend the schema. You can store all the rfc2307
>> attributes and objects (posixAccount, posixGroup, uidNumber,gidNumber. .
>> .) in the m$ schema that ships with S4.
> Too bad my AD controllers are M$ W2k3, w/o rfc2307 extension :( That's
> why I'm stuck with rid.

A supported version of Windows Server 2003 (aka the 2003R2) has the
RFC2307 extensions in the schema. The installation of the R2 service
pack extends the schema to include RFC2307, your windows admins simply
don't get a choice over that bit.

They don't get populated by default however so that is another battle to
be had, but it is a lot easier to win than a schema extension.

JAB.

--
Jonathan A. Buzzard Email: jonathan (at) buzzard.me.uk
Fife, United Kingdom.

[NdK]

Il 05/08/2012 12:32, Jonathan Buzzard ha scritto:

> A supported version of Windows Server 2003 (aka the 2003R2) has the
> RFC2307 extensions in the schema. The installation of the R2 service
> pack extends the schema to include RFC2307, your windows admins simply
> don't get a choice over that bit.

Good to know. They can't use unmaintained servers (Italian law requires
to update at least every 6 months...), so they must have it...

> They don't get populated by default however so that is another battle to
> be had, but it is a lot easier to win than a schema extension.

That's for sure :)
But maybe I can win this (after summer holidays).

BYtE,
Diego.

[steve]

On 04/08/12 22:06, NdK wrote:
> Il 04/08/2012 21:13, steve ha scritto:
>

> Uh? "wide links" seems a bad idea to me... At least from a security
> perspective.
> Why a single home directory? We have a single NFS share containing
> folders for the two domains and inside those a folder for each home.
> We are trying to migrate away from that, preferring a '[homes]' share
> where users will place the data they want to have available on every PC.
> This way even Firefox should work...
>

Hi Diego
We have home directories like:
home2/staff
home2/students/7a
home2/students/7b

Winbind allows only one template homedir and all user home folders must
reside there (or tell me otherwise).

The only way we can have what we want is:
1. use nss-ldapd and store the true uinixHomeDirectory in AD
2. winbind. We have a symlink in template homedir to the real data. For
that we need wide links.


Cheers,
Steve

[Jonathan Buzzard]

On 07/08/12 15:10, steve wrote:
> On 04/08/12 22:06, NdK wrote:
>> Il 04/08/2012 21:13, steve ha scritto:
>>
>
>> Uh? "wide links" seems a bad idea to me... At least from a security
>> perspective.
>> Why a single home directory? We have a single NFS share containing
>> folders for the two domains and inside those a folder for each home.
>> We are trying to migrate away from that, preferring a '[homes]' share
>> where users will place the data they want to have available on every PC.
>> This way even Firefox should work...
>>
> Hi Diego
> We have home directories like:
> home2/staff
> home2/students/7a
> home2/students/7b
>
> Winbind allows only one template homedir and all user home folders must
> reside there (or tell me otherwise).
>
> The only way we can have what we want is:
> 1. use nss-ldapd and store the true uinixHomeDirectory in AD
> 2. winbind. We have a symlink in template homedir to the real data. For
> that we need wide links.
>

3. Use winbind to store the true unixHomeDirectory in AD.

JAB.

--
Jonathan A. Buzzard Email: jonathan (at) buzzard.me.uk
Fife, United Kingdom.

[steve]

On 07/08/12 16:15, Jonathan Buzzard wrote:
> On 07/08/12 15:10, steve wrote:
>> On 04/08/12 22:06, NdK wrote:
>>> Il 04/08/2012 21:13, steve ha scritto:
>>>
>>
>>> Uh? "wide links" seems a bad idea to me... At least from a security
>>> perspective.
>>> Why a single home directory? We have a single NFS share containing
>>> folders for the two domains and inside those a folder for each home.
>>> We are trying to migrate away from that, preferring a '[homes]' share
>>> where users will place the data they want to have available on every PC.
>>> This way even Firefox should work...
>>>
>> Hi Diego
>> We have home directories like:
>> home2/staff
>> home2/students/7a
>> home2/students/7b
>>
>> Winbind allows only one template homedir and all user home folders must
>> reside there (or tell me otherwise).
>>
>> The only way we can have what we want is:
>> 1. use nss-ldapd and store the true uinixHomeDirectory in AD
>> 2. winbind. We have a symlink in template homedir to the real data. For
>> that we need wide links.
>>
>
> 3. Use winbind to store the true unixHomeDirectory in AD.
>

Hi
If I store unixHomeDirectory in AD, winbind seems to ignore it. As far
as it's concerned, all home directories have to be in template homedir.

How would I use winbind to store it? This is why we tend toward 1.
nss-ldapd pulls all of rfc2307 from AD. winbind seems to recognise only
uidNumber and gidNumber. It doesn't sem to give you any control over
login shell and unixHomeDirectory. Everyone has the same shell and homedir.

Cheers,
Steve

[Jonathan Buzzard]

Well it's read only, winbind pulls the information from the AD, but take
out your template homedir/shell lines from smb.conf and do something like

winbind nss info = rfc2307
winbind expand groups = 2
winbind nested groups = yes
winbind enum users = yes
winbind enum groups = yes

Note you can get nested groups this way, something I don't think
nss-ldapd provides. It does work I have it in production for over 1500
users right now with some 900 active SMB sessions.

JAB.

--
Jonathan A. Buzzard Email: jonathan (at) buzzard.me.uk
Fife, United Kingdom.

[steve]

Hi Jonathan
Is that with Samba3 or 4? I just tried it with Samba4 with
unixHomeDirectory in AD. I removed template homedir =, created the user
directory and gave it the correct permissions, but logging in, winbind
tries to create the directory:
su steve2
Creating directory ''.
Unable to create and initialize directory ''.
su: Permission denied

Cheers,
Steve

[Steven Schlegel]

Hey Steve,

I knew the error "Can't initialize directory" with the auto-create
method of pam+winbind for home directories as well,
but I think my setup is a little bit different than yours...

My setup looks like this:

- 50 linux-server
- 5 AD secondary DC's (Active Directory w2k8 R2)
- 1 Master-DC (Active Directory w2k8 R2)

The linux-server were setup with RHEL 5 (nearly half of all).
Approx. 15 server were setup with Oracle Linux 6.2 (nearly the same like RHEL).

Do you use the same Linux-Version for your clients (e.g. servers)?
If so just try to put the same pam-lines (/etc/pam.d/system-auth) into
the file password-auth file (/etc/pam.d/password-auth).

These are my files:
--> /etc/pam.d/system-auth <--
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth required pam_env.so
auth sufficient pam_unix.so likeauth nullok
auth sufficient pam_krb5.so use_first_pass
auth sufficient pam_smb_auth.so use_first_pass nolocal
auth sufficient pam_winbind.so use_first_pass
require_membership_of=g-gr-eo-it-io-dc,g-gr-eo-it-ao
auth required pam_deny.so

account required pam_unix.so broken_shadow
account sufficient pam_succeed_if.so uid < 500 quiet
account sufficient pam_krb5.so
account sufficient pam_winbind.so
account required pam_permit.so

password requisite pam_cracklib.so try_first_pass retry=3
password sufficient pam_unix.so md5 shadow nullok try_first_pass use_authtok
password sufficient pam_krb5.so use_authtok
password sufficient pam_winbind.so use_authtok
password required pam_deny.so

session required pam_limits.so
session [success=1 default=ignore] pam_succeed_if.so service in crond
quiet use_uid
session required pam_unix.so
session optional pam_krb5.so
session required pam_mkhomedir.so skel=/etc/skel umask=0077

--> /etc/pam.d/password-auth <--
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth required pam_env.so
auth sufficient pam_unix.so likeauth nullok
auth sufficient pam_krb5.so use_first_pass
auth sufficient pam_smb_auth.so use_first_pass nolocal
auth sufficient pam_winbind.so use_first_pass
require_membership_of=g-gr-eo-it-io-dc,g-gr-eo-it-ao
auth required pam_deny.so

account required pam_unix.so broken_shadow
account sufficient pam_succeed_if.so uid < 500 quiet
account sufficient pam_krb5.so
account sufficient pam_winbind.so
account required pam_permit.so

password requisite pam_cracklib.so try_first_pass retry=3
password sufficient pam_unix.so md5 shadow nullok try_first_pass use_authtok
password sufficient pam_krb5.so use_authtok
password sufficient pam_winbind.so use_authtok
password required pam_deny.so

session required pam_limits.so
session [success=1 default=ignore] pam_succeed_if.so service in crond
quiet use_uid
session required pam_unix.so
session optional pam_krb5.so
session required pam_mkhomedir.so skel=/etc/skel umask=0077

And my smb.conf looks like this:
# GLOBAL PARAMETERS
[global]
workgroup = <MY-WORKGROUP>
realm = <MY-DOMAIN.LCL>
password server = *
preferred master = no
server string = <YOUR> File-Server
security = ads
encrypt passwords = yes
local master = no
log level = 1
log file = /var/log/samba/%m
max log size = 50
#printcap name = cups
#printcap = cups
printcap = /dev/null
winbind enum users = Yes
winbind enum groups = Yes
winbind use default domain = Yes
winbind nested groups = Yes
winbind separator = \\
winbind refresh tickets = yes
winbind offline logon = true
winbind trusted domains only = no
#winbind trusted domains only = yes
map untrusted to domain = Yes
allow trusted domains = yes
obey pam restrictions = no
idmap backend = tdb
idmap uid = 10000-600000
idmap gid = 10000-600000
#idmap config EOS : tdb
#idmap config EOS : 10000-100000
#idmap config DFD : tdb
#idmap config DFD : 110000-200000
#idmap config * : backend = tdb
#idmap config * : range = 10000-600000
passdb backend = tdbsam
;template primary group = "domain users"
#template shell = /bin/false
template shell = /bin/bash

winbind nss info = rfc2307

client use spnego = yes
client ntlmv2 auth = yes
restrict anonymous = 2
socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192

[homes]
comment = Heimatverzeichnisse
valid users = %S
path = /home/<DOMAIN>/
read only = yes
browseable = no
#verstecke "nicht-lesbare" Verzeichnisse
hide unreadable = yes
#verstecke "nicht-schreibbare" Dateien u. Ordner
hide unwriteable files = yes
create mask = 0700
directory mask = 0700


When you login to one of my linux box with a user called "schlegels",
the home directory
will be created like this: /home/<DOMAIN>/schlegels


Oddjobd is not working for me... I don't know exactly if my setup is
the same like yours, because
I'm not able to read the whole conversation (too many things to do).


Cheers and good luck,

Steven

2012/8/8 steve <st...@steve-ss.com>:

[Jonathan Buzzard]

Do you think it is likely that I would have a production file server
system in place with over 900 active SMB connections using an Alpha
release piece of software?

I don't even use 3.6 yet because it is showing too many issues in testing.

JAB.

--
Jonathan A. Buzzard Email: jonathan (at) buzzard.me.uk
Fife, United Kingdom.

[steve]

Thanks Jonathan
I got it working. It needed a schema_mode line:
idmap config MYDOMAIN:schema_mode = rfc2307

I can now finally remove wide links = Yes :-)

nss-winbind seems slow. You can see the results of getent passwd
appearing one at a time. With nss-ldapd, the second time you do a
getent, it's instantaneous. Is there perhaps a cache I'm missing for
winbind? (I have nscd turned off)

Cheers,
Steve

[Jonathan Buzzard]

Noting that nscd and winbind don't work properly together, the settings
I use are

idmap cache time = 604800
idmap negative cache time = 20
winbind cache time = 600

Performance seems good to me, especially once cached.

JAB.

--
Jonathan A. Buzzard Email: jonathan (at) buzzard.me.uk
Fife, United Kingdom.

[Jeremy Allison]

On Wed, Aug 08, 2012 at 09:40:02AM +0100, Jonathan Buzzard wrote:
>
> Do you think it is likely that I would have a production file server
> system in place with over 900 active SMB connections using an Alpha
> release piece of software?
>
> I don't even use 3.6 yet because it is showing too many issues in testing.

Don't forget to log bugs against 3.6.x if you are seeing problems
in test !

That's the only way we'll get to know about them and fix them.

Cheers,

Jeremy.

[steve]

Much better. After e.g. 4 or 5 getent's it speeds up considerably.
Presumably getent populates the cache?
Cheers,
Steve