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!


--
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/options/samba

Reply via email to