[Samba] winbind and existing UIDs

[Gaiseric Vandal]

I don't think you would want to install SFU to actually provide sevices 
but just to enable the uid and other "unix" parameters  on the user 
account properties in the Active Directory Users and Groups console in 
Windows.  SFU unix is pretty useless otherwise.

This is just a guess but maybe you could then manually set/change the 
uid for the windows side.   In which case Samba would see that the 
imapping entry has already been taken care of and will not try to create 
an entry -  which means you then wouldn't need to let samba write to 
active directory anyway.


But as I said, I am just guessing at this point.



On 02/04/10 11:47, Liam Gretton wrote:
> On 04/02/2010 15:00, Gaiseric Vandal wrote:
>> On 02/04/10 04:07, Liam Gretton wrote:
>>>
>>> What I've done to get round this is to use the ldap backend for
>>> winbind, and create the mappings myself. This seems to work perfectly
>>> well but I can't believe there's not a means within winbind to use the
>>> account username to look up UIDs from an existing range.
>
>> It looks like from the Samba how to documentation that you might want to
>> use the RID backend-  which would use the Active Directory to store the
>> IDMAP info instead of a standalone LDAP server.
>
> As I understand it, that will just derive a new UID from the RID. I 
> need winbind to use existing UIDs. Also, writing anything back to the 
> AD is probably out of the question in our environment.
>
>> Also, MS Services for Unix uses relies on unix attributes -  I don't
>> think it has to expand the schema when installed.  But if you install it
>> it may give you the option to tweak the uid.
>
> Installing SFU isn't an option, unfortunately.
>
>> I would want to point out that under Sun's Samba 3.0.3x release I have
>> had a lot of problems with domain trusts with a Windows 2003 server
>> (mixed mode) and the idmapping cache- even with idmapping in LDAP.  The
>> PDC and one BDC are running 3.0.3x.    I have a 2nd BDC running Samba
>> 3.4.x (compiled from source) which seems to handle this a lot better.
>
> I've only been testing so far but haven't encountered any problems yet 
> with 3.0.34 and 3.0.37. Doesn't mean I won't at some point though!
>