samba - Feb 2015 - Winbind backend : rid is too much underappreciated

I just came to the conclusion that the rid backend has been very much
underappreciated. Too much mental inertia about how things used to be made?

After strugling for two days to configure a member server against a Samba Active
Directory  with the ad/RFC2307 backend, I turned to the rid backend and voil?!
all my problems are gone. Having to manually edit uids/gids in UNIX Attributes
under RSAT does really suck! The Administrator account is never correctly mapped
and setting permissions on the member server becomes a PITA. All kinds of
glitches become apparent.

Deterministic conversion from SID to UID rocks! Simple and elegant. Everything
is working in just a few minutes. Great! More people should know about this.
Just use the same ranges in all your servers and you will have consistent IDs in
all machines.

And for really large installations theres the autorid backend!

How come this is not more widely known? Even the Samba Wiki page about the RID
backend is empty!

> Deterministic conversion from SID to UID rocks! Simple and elegant.  
> Everything is working in just a few minutes. Great! More people  
> should know about this.
> Just use the same ranges in all your servers and you will have  
> consistent IDs in all machines.
>
The icing on the cake, as they say, could be a small schema extension  
to the Active Directory. Then, on  domain provision with the  
samba-tool we would input the wanted rid back end range. This would be  
  read by every member server and automatically configured. The  
benefits of centralized management of UID/GID without the pain.

Hello Miguel,

Am 21.02.2015 um 21:05 schrieb Miguel Medalha:
> After strugling for two days to configure a member server against a
> Samba Active Directory  with the ad/RFC2307 backend, I turned
> to the rid backend and voil?! all my problems are gone.
What problems did you had to get it running? I find it simple to setup.
And there's documentation about it in the Wiki, too. For setting up
RFC2307 in your AD and how member servers have to be configured (incl.
smb.conf example).


> Having to manually edit uids/gids in UNIX Attributes under
> RSAT does really suck!
https://bugzilla.samba.org/show_bug.cgi?id=10909
My patch is already in master and currently in autobuild for 4.2. It
will allow you to create RFC2307 enabled accounts via samba-tool.


> The Administrator account is never correctly mapped and setting
> permissions on the member server becomes a PITA.
What do you mean with "admin is never correctly mapped"?

And what's wrong with the permission settings on members? From ACL
settings side (chown/chgrp or via Windows tools), there's no different,
what ID backend is used.


> How come this is not more widely known? Even the Samba Wiki page
> about the RID backend is empty!
I think most prefer the advantages of RFC2307.

The main reason why the Wiki page about it is still empty is, that I
didn't had time during the last weeks, to continue working on the
documentation. :-) But all important about it, including an example, you
also find in
# man idmap_rid



Regards,
Marc

On 21/02/15 20:05, Miguel Medalha wrote:
> I just came to the conclusion that the rid backend has been very much
underappreciated. Too much mental inertia about how things used to be made?
>
> After strugling for two days to configure a member server against a Samba
Active Directory  with the ad/RFC2307 backend, I turned to the rid backend and
voil?! all my problems are gone. Having to manually edit uids/gids in UNIX
Attributes under RSAT does really suck! The Administrator account is never
correctly mapped and setting permissions on the member server becomes a PITA.
All kinds of glitches become apparent.
>
> Deterministic conversion from SID to UID rocks! Simple and elegant.
Everything is working in just a few minutes. Great! More people should know
about this.
> Just use the same ranges in all your servers and you will have consistent
IDs in all machines.
>
> And for really large installations theres the autorid backend!
>
> How come this is not more widely known? Even the Samba Wiki page about the
RID backend is empty!
>
>
>
Just recently a user had problems getting the rid backend to work, so it 
isn't the magic solution you are suggesting. Once you get your head 
around the winbind backends, it is easy to set them up. If you did have 
problems with the 'ad' backend, you had something set incorrectly.

Rowland

> 
> Just recently a user had problems getting the rid backend to work, so it 
> isn't the magic solution you are suggesting. Once you get your head 
> around the winbind backends, it is easy to set them up. If you did have 
> problems with the 'ad' backend, you had something set incorrectly.
> 
Do you have something against the rid backend? Which disavantadges do you 
see? It simply works!

The problems I had came most probably from using the AD Controller also as 
file server. I know, that's not perfect but sometimes things have to be 
done in a certain way in certain scenarios for particular reasons. The 
internal winbind maps users/groups to a range starting with 3000000. 
Administrator has a UID of 0. How would you fill up the UNIX Attributes 
tab for Administrator?

> Just recently a user had problems getting the rid backend to work, so it 
> isn't the magic solution you are suggesting. Once you get your head 
> around the winbind backends, it is easy to set them up. If you did have 
> problems with the 'ad' backend, you had something set incorrectly.
What kind of problems can you have? I did it with these lines:

	idmap config * :backend = tdb
	idmap config * :range = 10000-99999
	idmap config DOMAIN : backend = rid
	idmap config DOMAIN : range = 100000-199999

Everything just works and getent/id show me UIDs/GIDs that imediately tell 
me which SID they correspond to.

What do you think of this possible extension to the rid backend?

A small schema extension would be done to the SAMBA Active Directory. Then, 
on  domain provision with the samba-tool we would input the wanted rid 
backend range. A single parameter in the smb.conf of each new member 
server would make it read this information from the DC and automatically 
configure itself with that range. The benefits of centralized management 
of UID/GID without the pain of manual labor.

On Sat, 2015-02-21 at 20:05 +0000, Miguel Medalha wrote:
> I just came to the conclusion that the rid backend has been very much
> underappreciated. Too much mental inertia about how things used to be
> made?
> 
> After strugling for two days to configure a member server against a
> Samba Active Directory  with the ad/RFC2307 backend, I turned to the
> rid backend and voil! all my problems are gone. Having to manually
> edit uids/gids in UNIX Attributes under RSAT does really suck! The
> Administrator account is never correctly mapped and setting
> permissions on the member server becomes a PITA. All kinds of glitches
> become apparent.
> 
> Deterministic conversion from SID to UID rocks! Simple and elegant.
> Everything is working in just a few minutes. Great! More people should
> know about this.
> Just use the same ranges in all your servers and you will have
> consistent IDs in all machines.
> 
> And for really large installations theres the autorid backend!
> 
> How come this is not more widely known? Even the Samba Wiki page about
> the RID backend is empty! 
What I would like to do, if I ever get the time, energy or someone else
does it for me, is to have a rid backend that uses the trustPosixOffset
attribute, and calculates ID values just like AD claims to do for the
never-used POSIX subsystems. 

If we could detect new installs, then clients and the AD DC would use
this new autorid_trustPosixOffset by default, but clients using rfc2307
would also 'just work' (minus the benefits of ID_TYPE_BOTH) as we filled
that in anyway.

Then, have an optional mode in Samba that when we create users, we fill
in the uidNumber value and gidNumber values with whatever the supported
mode on the RID master or PDC emulator AD DC would create (using the
FSMO master so there is only one allocator). 

The big challenge we have in this area is that we have existing
installations that we can't just change the defaults on, and so our
ideal solution isn't the same one we could do if we started from a blank
slate (cue sssd comments here). 

All that said, I do regret that we didn't make the rfc2307 mode the
default in the AD DC prior to 4.0. 

I'm snowed under on so many other things, but if anyone wants to work on
this, do le me know.  Perhaps a good GSoC project?

Thanks,

Andrew Bartlett

-- 
Andrew Bartlett                       http://samba.org/~abartlet/
Authentication Developer, Samba Team  http://samba.org
Samba Developer, Catalyst IT          http://catalyst.net.nz/services/samba

On 22/02/15 09:05, Miguel Medalha wrote:
> I just came to the conclusion that the rid backend has been very much
underappreciated. Too much mental inertia about how things used to be made?
>
> After strugling for two days to configure a member server against a Samba
Active Directory  with the ad/RFC2307 backend, I turned to the rid backend and
voil?! all my problems are gone. Having to manually edit uids/gids in UNIX
Attributes under RSAT does really suck! The Administrator account is never
correctly mapped and setting permissions on the member server becomes a PITA.
All kinds of glitches become apparent.
I agree. We have a majorly complex AD here: multiple domains in multiple
trusted forests - each with a different IT group responsible, none of
whom are interested in supporting Samba. We had problems with different
users (from different domains) being mapped to the same UID - let's face
it, you can't get worse than that. Once we moved to "backend =
rid" and
formally mapped each domain to its own range, all such problems
disappeared. The great thing is we do that rid mapping in an include
file - and just make sure all Samba servers have the same file - so now
all these thousands of AD accounts in multiple forests will map to the
same unique Unix uid on any of our Samba servers - sweet! We could even
bring NFS into this mess if we choose to :-)

Long live rid! :-)


-- 
Cheers

Jason Haar
Corporate Information Security Manager, Trimble Navigation Ltd.
Phone: +1 408 481 8171
PGP Fingerprint: 7A2E 0407 C9A6 CAF6 2B9F 8422 C063 5EBB FE1D 66D1

Am 22.02.2015 um 02:18 schrieb Andrew Bartlett:
> On Sat, 2015-02-21 at 20:05 +0000, Miguel Medalha wrote:
>> I just came to the conclusion that the rid backend has been very much
>> underappreciated. Too much mental inertia about how things used to be
>> made?
>>
>> After strugling for two days to configure a member server against a
>> Samba Active Directory  with the ad/RFC2307 backend, I turned to the
>> rid backend and voil! all my problems are gone. Having to manually
>> edit uids/gids in UNIX Attributes under RSAT does really suck! The
>> Administrator account is never correctly mapped and setting
>> permissions on the member server becomes a PITA. All kinds of glitches
>> become apparent.
>>
>> Deterministic conversion from SID to UID rocks! Simple and elegant.
>> Everything is working in just a few minutes. Great! More people should
>> know about this.
>> Just use the same ranges in all your servers and you will have
>> consistent IDs in all machines.
>>
>> And for really large installations theres the autorid backend!
>>
>> How come this is not more widely known? Even the Samba Wiki page about
>> the RID backend is empty! 
> 
> What I would like to do, if I ever get the time, energy or someone else
> does it for me, is to have a rid backend that uses the trustPosixOffset
> attribute, and calculates ID values just like AD claims to do for the
> never-used POSIX subsystems. 
The sad thing is that this can't work, because it doesn't handle
transitive trusts.

What we really need are autorid backends with a global storage, one for AD
and one for LDAP.
> If we could detect new installs, then clients and the AD DC would use
> this new autorid_trustPosixOffset by default, but clients using rfc2307
> would also 'just work' (minus the benefits of ID_TYPE_BOTH) as we
filled
> that in anyway.
> 
> Then, have an optional mode in Samba that when we create users, we fill
> in the uidNumber value and gidNumber values with whatever the supported
> mode on the RID master or PDC emulator AD DC would create (using the
> FSMO master so there is only one allocator). 
> 
> The big challenge we have in this area is that we have existing
> installations that we can't just change the defaults on, and so our
> ideal solution isn't the same one we could do if we started from a
blank
> slate (cue sssd comments here). 
> 
> All that said, I do regret that we didn't make the rfc2307 mode the
> default in the AD DC prior to 4.0. 
I'd really like to avoid spreading rfc2307 as much as possible...

metze

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.samba.org/pipermail/samba/attachments/20150303/f3888a92/attachment.pgp>