samba - Jan 2013 - Samba4 Winbind - is it really not possible to be sensible?

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. 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.

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.

Rob

2013-01-25 20:43 keltez?ssel, Rob McCorkell ?rta:
> 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. 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.
>
> 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.
>
> Rob
If you provision/run with idmap_ldb:use rfc2307 then you can assign each 
user/group a uidNumber/gidNumber which then is/can be obeyed by samba/nslcd.

Regards

Geza Gemes

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.

-- 
Matthieu Patou
Samba Team
http://samba.org