Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
[Samba] Winbind backend : rid is too much underappreciated
1,117 views
Skip to first unread message
Miguel Medalha
Feb 21, 2015, 3:06:05 PM2/21/15
to
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!
miguel...@sapo.pt
Feb 21, 2015, 3:31:31 PM2/21/15
to
> 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.
>
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.
--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/options/samba
Marc Muehlfeld
Feb 21, 2015, 4:10:28 PM2/21/15
to
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
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.
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!
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.
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!
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
Rowland Penny
Feb 21, 2015, 4:42:36 PM2/21/15
to
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.
>
> 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.
>
> 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
Miguel Medalha
Feb 21, 2015, 5:15:51 PM2/21/15
to
>
> 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.
>
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?
Miguel Medalha
Feb 21, 2015, 5:24:36 PM2/21/15
to
> 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:
> 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.
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.
Miguel Medalha
Feb 21, 2015, 5:37:06 PM2/21/15
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.
Marc Muehlfeld
Feb 21, 2015, 5:45:13 PM2/21/15
to
Am 21.02.2015 um 23:15 schrieb Miguel Medalha:
> Do you have something against the rid backend? Which disavantadges do you
> see? It simply works!
_My_ personal disadvantage with idmap_rid is, that you have to define
> Do you have something against the rid backend? Which disavantadges do you
> see? It simply works!
stuff like the shell on a per server and not on a per user base. You can
decite if _all_ users should have /bin/bash or alle /bin/false. RFC2307
allows you to centralized set this per user. So admins have a shell for
their user account and no one else. With RID backend, all users need a
shell, and I have to take care via sshd.conf, etc. that only admin users
are allowed to really log in.
> Administrator has a UID of 0. How would you fill up the UNIX Attributes
> tab for Administrator?
ACLs on Linux-Samba servers are set as root using POSIX ACLs. On windows
servers it's done the windows way without any problems. I can administer
my Samba printserver by granting privileges like described in the Wiki.
Haven't seen any problems since setup 2.5 years.
Regards,
Marc
Miguel Medalha
Feb 21, 2015, 6:39:12 PM2/21/15
to
>
> My domain admin at work has UID 30253. I haven't seen any problems yet.
> ACLs on Linux-Samba servers are set as root using POSIX ACLs. On windows
> servers it's done the windows way without any problems. I can administer
> my Samba printserver by granting privileges like described in the Wiki.
> Haven't seen any problems since setup 2.5 years.
>
My problems came from using the Samba AD Domain Controller as a file
server. In this particular case I could not avoid it, for reasons that
would take too much effort to explain. When I later had to join a member
server to the network, things started to complicate.
In this case I don't need any Active directory users to have a shell on the
Linux servers, including administrators. Root will do. I am not using
POSIX ACLs either. I use acl_xattr only. All clients in the network are
Windows machines, only servers are Linux.
Andrew Bartlett
Feb 21, 2015, 8:19:21 PM2/21/15
to
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
> 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
> 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
> 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!
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
Rowland Penny
Feb 22, 2015, 3:25:07 AM2/22/15
to
On 21/02/15 22:23, Miguel Medalha wrote:
>> 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.
>
Taking your example 'idmap config DOMAIN : range = 100000-199999' it is
>> 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.
>
very easy, you just need users whose RIDs are larger than 200000, these
users will be ignored.
Something similar was problem wrong with the 'ad' backend when you tried
it, failing that it was probably a lack of 'uidNumber' & 'gidNumber' in AD.
As Marc has pointed out, with the 'rid' backend you do not get to set
home dirs & shells on a per user basis.
Rowland
Miguel Medalha
Feb 22, 2015, 5:27:51 PM2/22/15
to
> >
> > idmap config * :backend = tdb
> > idmap config * :range = 10000-99999
> > idmap config DOMAIN : backend = rid
> > idmap config DOMAIN : range = 100000-199999
> >
>
> > idmap config * :backend = tdb
> > idmap config * :range = 10000-99999
> > idmap config DOMAIN : backend = rid
> > idmap config DOMAIN : range = 100000-199999
> >
>
> Taking your example 'idmap config DOMAIN : range = 100000-199999' it is
> very easy, you just need users whose RIDs are larger than 200000, these
> users will be ignored.
>
> Something similar was problem wrong with the 'ad' backend when you tried
> it, failing that it was probably a lack of 'uidNumber' & 'gidNumber' in
AD.
>
Nope! I had 'uidNumber' & 'gidNumber' in AD.
> very easy, you just need users whose RIDs are larger than 200000, these
> users will be ignored.
>
> Something similar was problem wrong with the 'ad' backend when you tried
> it, failing that it was probably a lack of 'uidNumber' & 'gidNumber' in
AD.
>
Well, maybe I should explain everything in a orderly way, which, being too
tired, I hadn't the patience to do the other day.
I had a AD DC running Samba 4.1.x for some time, doubling as a file server.
Yes, I know it is not the recommended way, but sometimes real life leads
us into particular situations. (It was a long-thought decision, but it
would be boring to go through the details here.)
Then, two days ago I finally got another server and I wanted to join it to
the domain as a member server. All went smoothly from that point of view.
I then went to ADUC (Active Directory Users and Computers) and started to
fill the 'UNIX Attributes' tab with 'uidNumber' & 'gidNumber'. I started
with the Administrator account, accepting the proposed uid 10000 and so
on. Then, bang, I couldn't connect with my user profile when logging in
to the domain from the same Windows machine I always used.
I had previously noticed that getent on the AD DC gave me ids in a range
starting with 3000000, and I thought that this could be the reason why
the Administrator account had lost access to essential folders on the
server, since the default range and the range entered with ADUC didn't
match. I then tried to give some users the same id in the 3000000 range
reported by getent on the DC, except for Administrator, to which I gave
id 0, as again reported by getent on the DC. Now, I could see all the
users from the member server, except for Administrator and except again
for 'getent group' unless I specified the group. I must add that 'wbinfo
-u/-g' always showed me all users and groups, including Administrator.
(Yes, I have 'passwd: files winbind' 'and group: files winbind' in
/etc/nsswitch.conf. And yes I changed the idmap config range to
3000000-4000000 in smb.conf for the experience I just described)
I tried to set permissions on a share from Windows, to which the reply was
that I (Administrator) did not have the permissions to set or even view
permissions. And yes, I had granted all the necessary rights to
Administrator and Domain Admins.
After a lot of trials including username mapping and so on, I decided to
try the rid backend, which worked immediately.
I am probably commiting some basic mistake that is ridiculous from the
developers' point of view. I am not a developer and my knowledge of the
inner workings of Samba is limited, although I have been using it
successfully for more than 10 years with file servers and NT4-style
domain controllers. I just feel that simply following the instructions on
the Wiki is not enough to painlessly configure a member server.
Maybe some unfortunate decisions have been made through the development of
the Samba AD DC regarding winbind and id mapping that led to confusing
users. Please note that I am not bitching or even complaining. I admire
the work of the Samba team and I grateful for it. But maybe real life and
real problems led to some decisions that were not the easiest for users.
Than you for you patience
--------
As an aside, username mapping does not seem to be working in the usual way,
as described in the man page. If I entered more than one name after the
'=' sign, mapping stopped working. For example:
'root = Administrator' did map root to administrator, getent showed me
Administrator
'root = Administrator admin' did not work, getent ceased to show
Administrator
The use of !root as described in the manual also caused getent not to show
Administrator
Miguel Medalha
Feb 22, 2015, 5:54:37 PM2/22/15
to
I must add that I am using the Sernet Samba 4.1.16 pakages on both servers,
CentOS 7 on the AD DC and CentOS 6.6 on the member server.
Rowland Penny
Feb 23, 2015, 5:44:21 AM2/23/15
to
On 22/02/15 22:27, Miguel Medalha wrote
>
> Nope! I had 'uidNumber' & 'gidNumber' in AD.
>
> Well, maybe I should explain everything in a orderly way, which, being too
> tired, I hadn't the patience to do the other day.
>
>
> I had a AD DC running Samba 4.1.x for some time, doubling as a file server.
> Yes, I know it is not the recommended way, but sometimes real life leads
> us into particular situations. (It was a long-thought decision, but it
> would be boring to go through the details here.)
OK, I understand, even though it is not recommended, sometimes you just
have to do it :-)
>
> Then, two days ago I finally got another server and I wanted to join it to
> the domain as a member server. All went smoothly from that point of view.
> I then went to ADUC (Active Directory Users and Computers) and started to
> fill the 'UNIX Attributes' tab with 'uidNumber' & 'gidNumber'. I started
> with the Administrator account, accepting the proposed uid 10000 and so
> on. Then, bang, I couldn't connect with my user profile when logging in
> to the domain from the same Windows machine I always used.
By default, Administrator is given the 'xidNumber' 0 which is also the
id for the Unix user 'root', by changing this you made 'Administrator' a
normal Unix user with all the permissions (or rather lack of) this
entails. You probably needed to update the 'security' tab on the
profiles share.
>
> I had previously noticed that getent on the AD DC gave me ids in a range
> starting with 3000000, and I thought that this could be the reason why
> the Administrator account had lost access to essential folders on the
> server, since the default range and the range entered with ADUC didn't
> match. I then tried to give some users the same id in the 3000000 range
> reported by getent on the DC, except for Administrator, to which I gave
> id 0, as again reported by getent on the DC. Now, I could see all the
> users from the member server, except for Administrator and except again
> for 'getent group' unless I specified the group. I must add that 'wbinfo
> -u/-g' always showed me all users and groups, including Administrator.
wbinfo works directly on AD, getent goes via Unix. When you give the
Administrator user the id 0, getent will only return the first user it
finds, if you want the info for Administrator to be returned, change the
passwd line in /etc/nsswitch.conf to 'passwd winbind compat' (note,
this on debian, 'compat' may be 'files' on your distro)
NOTE: once you have finished testing, please put the line in
/etc/nsswitch.conf back to what it was, or you will not have a root user:-D
>
>
> (Yes, I have 'passwd: files winbind' 'and group: files winbind' in
> /etc/nsswitch.conf. And yes I changed the idmap config range to
> 3000000-4000000 in smb.conf for the experience I just described)
If, as you say, your users have a 'uidNumber' in the '3000000-4000000'
range *and* Domain Users has a 'gidNumber' in the same range, it should
have worked.
>
>
> I tried to set permissions on a share from Windows, to which the reply was
> that I (Administrator) did not have the permissions to set or even view
> permissions. And yes, I had granted all the necessary rights to
> Administrator and Domain Admins.
This was possibly caused by a misunderstanding, Administrator on the DC
is mapped to 'root' so has all the permissions of 'root' i.e. it can do
anything. On a member server it is different, you have to explicitly map
root yourself.
>
> After a lot of trials including username mapping and so on, I decided to
> try the rid backend, which worked immediately.
Yes, it is a lot easier, but only if you do not require to set home dirs
& shells per user.
>
>
> I am probably commiting some basic mistake that is ridiculous from the
> developers' point of view. I am not a developer and my knowledge of the
> inner workings of Samba is limited, although I have been using it
> successfully for more than 10 years with file servers and NT4-style
> domain controllers. I just feel that simply following the instructions on
> the Wiki is not enough to painlessly configure a member server.
I am not a developer either but I do have permission to change the wiki
, so if you struggled with the wiki, is there any chance you could tell
us what you feel is wrong or missing from the member-server page, unless
we get feedback we do not really know that it needs to be updated.
>
> Maybe some unfortunate decisions have been made through the development of
> the Samba AD DC regarding winbind and id mapping that led to confusing
> users. Please note that I am not bitching or even complaining. I admire
> the work of the Samba team and I grateful for it. But maybe real life and
> real problems led to some decisions that were not the easiest for users.
>
>
> Than you for you patience
>
> --------
>
> As an aside, username mapping does not seem to be working in the usual way,
> as described in the man page. If I entered more than one name after the
> '=' sign, mapping stopped working. For example:
>
> 'root = Administrator' did map root to administrator, getent showed me
> Administrator
>
> 'root = Administrator admin' did not work, getent ceased to show
> Administrator
>
> The use of !root as described in the manual also caused getent not to show
> Administrator
All I can say here is that it works for me.
Rowland
>
> Nope! I had 'uidNumber' & 'gidNumber' in AD.
>
> Well, maybe I should explain everything in a orderly way, which, being too
> tired, I hadn't the patience to do the other day.
>
>
> I had a AD DC running Samba 4.1.x for some time, doubling as a file server.
> Yes, I know it is not the recommended way, but sometimes real life leads
> us into particular situations. (It was a long-thought decision, but it
> would be boring to go through the details here.)
have to do it :-)
>
> Then, two days ago I finally got another server and I wanted to join it to
> the domain as a member server. All went smoothly from that point of view.
> I then went to ADUC (Active Directory Users and Computers) and started to
> fill the 'UNIX Attributes' tab with 'uidNumber' & 'gidNumber'. I started
> with the Administrator account, accepting the proposed uid 10000 and so
> on. Then, bang, I couldn't connect with my user profile when logging in
> to the domain from the same Windows machine I always used.
id for the Unix user 'root', by changing this you made 'Administrator' a
normal Unix user with all the permissions (or rather lack of) this
entails. You probably needed to update the 'security' tab on the
profiles share.
>
> I had previously noticed that getent on the AD DC gave me ids in a range
> starting with 3000000, and I thought that this could be the reason why
> the Administrator account had lost access to essential folders on the
> server, since the default range and the range entered with ADUC didn't
> match. I then tried to give some users the same id in the 3000000 range
> reported by getent on the DC, except for Administrator, to which I gave
> id 0, as again reported by getent on the DC. Now, I could see all the
> users from the member server, except for Administrator and except again
> for 'getent group' unless I specified the group. I must add that 'wbinfo
> -u/-g' always showed me all users and groups, including Administrator.
Administrator user the id 0, getent will only return the first user it
finds, if you want the info for Administrator to be returned, change the
passwd line in /etc/nsswitch.conf to 'passwd winbind compat' (note,
this on debian, 'compat' may be 'files' on your distro)
NOTE: once you have finished testing, please put the line in
/etc/nsswitch.conf back to what it was, or you will not have a root user:-D
>
>
> (Yes, I have 'passwd: files winbind' 'and group: files winbind' in
> /etc/nsswitch.conf. And yes I changed the idmap config range to
> 3000000-4000000 in smb.conf for the experience I just described)
range *and* Domain Users has a 'gidNumber' in the same range, it should
have worked.
>
>
> I tried to set permissions on a share from Windows, to which the reply was
> that I (Administrator) did not have the permissions to set or even view
> permissions. And yes, I had granted all the necessary rights to
> Administrator and Domain Admins.
is mapped to 'root' so has all the permissions of 'root' i.e. it can do
anything. On a member server it is different, you have to explicitly map
root yourself.
>
> After a lot of trials including username mapping and so on, I decided to
> try the rid backend, which worked immediately.
& shells per user.
>
>
> I am probably commiting some basic mistake that is ridiculous from the
> developers' point of view. I am not a developer and my knowledge of the
> inner workings of Samba is limited, although I have been using it
> successfully for more than 10 years with file servers and NT4-style
> domain controllers. I just feel that simply following the instructions on
> the Wiki is not enough to painlessly configure a member server.
, so if you struggled with the wiki, is there any chance you could tell
us what you feel is wrong or missing from the member-server page, unless
we get feedback we do not really know that it needs to be updated.
>
> Maybe some unfortunate decisions have been made through the development of
> the Samba AD DC regarding winbind and id mapping that led to confusing
> users. Please note that I am not bitching or even complaining. I admire
> the work of the Samba team and I grateful for it. But maybe real life and
> real problems led to some decisions that were not the easiest for users.
>
>
> Than you for you patience
>
> --------
>
> As an aside, username mapping does not seem to be working in the usual way,
> as described in the man page. If I entered more than one name after the
> '=' sign, mapping stopped working. For example:
>
> 'root = Administrator' did map root to administrator, getent showed me
> Administrator
>
> 'root = Administrator admin' did not work, getent ceased to show
> Administrator
>
> The use of !root as described in the manual also caused getent not to show
> Administrator
Rowland
L.P.H. van Belle
Feb 24, 2015, 5:51:18 AM2/24/15
to
didnt we have the problem with backend to RID,
that the user ID wasnt always the same on different member servers.
and to keep that in line you had to copy the idmap.db to the other server?
Or am i mixing up other things now.
Best regards,
Louis
that the user ID wasnt always the same on different member servers.
and to keep that in line you had to copy the idmap.db to the other server?
Or am i mixing up other things now.
Best regards,
Louis
Rowland Penny
Feb 24, 2015, 6:15:08 AM2/24/15
to
On 24/02/15 10:50, L.P.H. van Belle wrote:
> didnt we have the problem with backend to RID,
> that the user ID wasnt always the same on different member servers.
> and to keep that in line you had to copy the idmap.db to the other server?
>
> Or am i mixing up other things now.
>
> Best regards,
>
> Louis
>
Yes, you are mixing things up now :-D
> didnt we have the problem with backend to RID,
> that the user ID wasnt always the same on different member servers.
> and to keep that in line you had to copy the idmap.db to the other server?
>
> Or am i mixing up other things now.
>
> Best regards,
>
> Louis
>
idmap.ldb is only found on DCs and hands out different numbers on each
DC, hence copying the idmap.ldb from the first DC to any subsequent DC.
Rowland
L.P.H. van Belle
Feb 24, 2015, 6:31:20 AM2/24/15
to
ah, ok, yes that was it.. ;-)
so for my understanding.
we use AD backend if we also want to use the RFC2307 extention (with winbind and schema_mode rfc2307)
and we can use RID if we want the windows user id with winbind.
and for RID we can use the server templete settings
and for AD can can set this per user seen the the Unix Attibutes tab in the windows tool
correct? (I still done understand the main difference between AD and RID.)
i just did read both man's but that does not make it more clear for me.
Greetz,
Louis
>-----Oorspronkelijk bericht-----
>Van: rowlan...@googlemail.com
>[mailto:samba-...@lists.samba.org] Namens Rowland Penny
>Verzonden: dinsdag 24 februari 2015 12:14
>Aan: sa...@lists.samba.org
>Onderwerp: Re: [Samba] Winbind backend : rid is too much
>underappreciated
so for my understanding.
we use AD backend if we also want to use the RFC2307 extention (with winbind and schema_mode rfc2307)
and we can use RID if we want the windows user id with winbind.
and for RID we can use the server templete settings
and for AD can can set this per user seen the the Unix Attibutes tab in the windows tool
correct? (I still done understand the main difference between AD and RID.)
i just did read both man's but that does not make it more clear for me.
Greetz,
Louis
>-----Oorspronkelijk bericht-----
>Van: rowlan...@googlemail.com
>[mailto:samba-...@lists.samba.org] Namens Rowland Penny
>Verzonden: dinsdag 24 februari 2015 12:14
>Aan: sa...@lists.samba.org
>Onderwerp: Re: [Samba] Winbind backend : rid is too much
>underappreciated
L.P.H. van Belle
Feb 24, 2015, 6:34:32 AM2/24/15
to
and while taking the microsoft message to drop the Unix extention support.
Isnt is good to switch to RID?
Louis
>-----Oorspronkelijk bericht-----
>Van: be...@bazuin.nl [mailto:samba-...@lists.samba.org]
>Namens L.P.H. van Belle
>Verzonden: dinsdag 24 februari 2015 12:30
Isnt is good to switch to RID?
Louis
>-----Oorspronkelijk bericht-----
>Van: be...@bazuin.nl [mailto:samba-...@lists.samba.org]
>Namens L.P.H. van Belle
>Verzonden: dinsdag 24 februari 2015 12:30
Rowland Penny
Feb 24, 2015, 6:51:16 AM2/24/15
to
very good version.
L.P.H. van Belle
Feb 24, 2015, 6:57:21 AM2/24/15
to
Great ! I needed to hear that, thanks ! :-)
So for me, to be ready for the future windows server, i need to witch to RID..
... wel.. new script options then.. ;-)
Greetz,
Louis
>-----Oorspronkelijk bericht-----
>Van: rowlan...@googlemail.com
>[mailto:samba-...@lists.samba.org] Namens Rowland Penny
>Verzonden: dinsdag 24 februari 2015 12:51
So for me, to be ready for the future windows server, i need to witch to RID..
... wel.. new script options then.. ;-)
Greetz,
Louis
>-----Oorspronkelijk bericht-----
>Van: rowlan...@googlemail.com
>[mailto:samba-...@lists.samba.org] Namens Rowland Penny
miguel...@sapo.pt
Feb 24, 2015, 8:54:28 AM2/24/15
to
> didnt we have the problem with backend to RID,
> that the user ID wasnt always the same on different member servers.
As long as the id ranges and base rid on each member servers' smb.
> that the user ID wasnt always the same on different member servers.
conf are kept the same, that cannot happen. The mapping from SIDs is
deterministic.
Jason Haar
Mar 1, 2015, 4:17:07 AM3/1/15
to
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 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?
>
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
0 new messages