Thanks for the explanation - I wasn't thinking too much about multiple
domains, and I guess it would be an issue. A potential solution would be
to have offsets for each domain, specified in smb.conf? If I didn't have
too much on my plate already I would have a look at the mapping code and
attempt to write a solution myself.
The 'solution' with the UID discrepancy between nslcd and Samba was to
feed back the nslcd UID back into Samba, then tell Samba to use those
UIDs instead. Oh, and while I am here I might as well bring a particular
bug to your attention - when Samba is set to use rfc2307, but no
uidNumber attribute exists for an object, the UID number gets allocated.
But once a uidNumber attribute is set, and the allocation has already
taken place, the allocated UID is used instead. I can't imagine that
this is the desired behaviour with rfc2307.
Thanks,
Rob
On 26/01/2013 7:25 PM, Matthieu Patou wrote:
On 01/25/2013 11:43 AM, Rob McCorkell wrote:
Samba3 allowed for the setting of idmaps and passdb backends to
configure how users were pulled in. This made integrating with
existing LDAP databases, other other forms of authentication easy,
since Samba could be configured to present the same UID and GID as
directly from the [insert other auth method here] system. All was good.
Unfortunately Samba4 seems to have removed much of that
functionality. I understand that in an AD context, passdb backend
doesn't really make very much sense, so removing that was fair. What
I do not understand is why Winbind cannot be configured to use
certain idmaps, more specifically the RID mapping.
First of all: resources, feel free to provide your implementation for
the rid backend.
Then also with AD winbindd we tried to not reproduce what has been
done with the original winbindd where we had a lot of options and
backend and after we realize that it wasn't such a good fit.
And having discussed about it for a long time RID backend is the
perfect example of the backend that seems very interesting at first
glance but that is not so in the long run as it works well only when
you have 1 domain.
We are still thinking on a RID like solution but that would scale with
more than one domain.
This would make it significantly easier to integrate LDAP
authenticating clients into Samba4, for example using nslcd to map
the UIDs and GIDs. The current implementation is forced into using
allocated *IDs, which are not consistent across machines.
But all in all this is not a big problem, since although machines get
different *IDs, they use the CIFS protocol which uses usernames
instead, so each machine knows who a user is. The problem is when a
server that runs Samba4 as a file server uses LDAP to get user
information. When a client connects, Samba4 the user UID which is
allocated. Samba4 then finds the home share, but since the UID on the
home share (dutifully mapped by nslcd from the RID on the end of the
objectSid) doesn't match the allocated one, it refuses access.
Can you configure nslcd to use the uidNumber/gidNumber ? if so one
solution could be (but just for samba only domain controller) to have
a mechanism that feeds back the randomly generated uid back to the
uidNumber fields
All that nslcd does in this case is map a UID to the RID from the
objectSid in LDAP. This is a very simple mapping - just get the end
of the string, where the first bit is the domain SID. Samba3
supported RID mapping in this fashion, but I do not understand why
this was not ported across to Samba4. It would only change the UIDs
and GIDs as seen by Samba, which as far as I know are used very
little within Samba, where the objectSid is used instead.
Of course, it could be that I have a massive misunderstanding of the
internals of Samba4, and there is a reason why this functionality
wasn't brought across.
No you don't but for the AD part we have for the moment a pretty
limited set of method to allocate UIDs/GIDs, sorry!
Matthieu.
--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/options/samba
