Winbind - functionality

[MICHAEL BROWN]

> Hello Mr. Bartlet,
> this does indeed allow import of uid/gid information into SAMBA 4 AD backend using non "msSFU" attributes.  Using
> the normal POSIX uid/gid LDAP attributes work great.  I can join SAMBA 3.4 to SAMBA 4 just fine.  The problem I am having
> with SAMBA 3.4 is that SAMBA is not recognizing the groups defined within the share areas within the smb.conf file.
> However, the user is pulled from the AD backend just fine (if the shares are configured with no groups).  Meaning,
> within the smb.conf file, I typically set group access to shares defined as:
> 
> [myshare]
> valid users = @Mygroup, @ThisGroup
> 
> To explain, I don't want to use Winbind at all.
> I have everything configured with nss-ldap within the nsswitch.conf file.
> Also, I have modified my ldap.conf file to pull this information from SAMBA 4's AD backend using the correct attributes
> defined within the Win2008 schema and the groups and users are picked up just like my OpenLDAP backend perfectly.
> Meaning, getent group and shadow pull just like the OpenLDAP backend calls.  I can't point smb.conf to AD via an
> LDAP call because it is wanting SAMBA attributes that are not within the Windows 2008 schema.
> Is there any way I can get SAMBA 3 to recognize the AD groups (just like it does the users) with nss-ldap?

>>I strongly recommend you use winbindd.  This is the Samba Team's
>>supported client for AD servers.  

>>If the problem was so easy that a simple nss_ldap invocation handled it
>>properly, we would not have 'wasted' so much time on winbind.  It was
>>developed for a very real reason.

>>Andrew Bartlett

I understand and I am not trying to induce any problems/hard feelings.  I understand a lot of work has gone into SAMBA.
However, if we start using winbind, will not our existing UID and GIDs set withing our existing backend will be useless?
Meaning, *ALL* of our production servers have files and directories based off of these static UID and GID numbers assigned within our
OpenLDAP backend.  I may be wrong here but If we introduce winbind, the UID and GID numbers will be changed based off of winbind
using the SID and multiplying, etc., to get a new UID/GID value that is not even close to our existing production environment.  No groups
or users would be recognized on folders and files due to incorrect UID/GID numbers.  I am talking about a lot of production file servers here.

So, is there a way/configuration setting to prevent winbind from taking existing, *statically set*, UID/GID numbers on our users and groups
and applying the SID multiplication to come up with a new UID/GID numbers for these existing POSIX users and groups?
If not, woe is me.



NOTICE - This communication may contain confidential and privileged information that is for the sole use of the intended recipient. Any viewing, copying or distribution of, or reliance on this message by unintended recipients is strictly prohibited.  If you have received this message in error, please notify us immediately by replying to the message and deleting it from your computer.