After speaking about winbind behaviour, back to my initial question:
migrating a Samba file server to another one replacing UID/GID database (it
was a Centrify database).
So we have files and directories owned by UNIX users on file system on the
old server, UID/GID are not into uidNumber/gidNumber but are known: we can
list users and groups to display every UID/GID used.
Of course what expected my client was all users continue to have access to
their files. To do that they started changing rights on the new file server
to 777... Users had access to their files but also to every files which
is.. discussable : )
So here I saw two option (777 is not an option) :
- keeping UID/GID by usage of uidNUmber and gidNumber which are always
available in AD (perhaps not in AD 2016, I did not tested).
This is working but not with Winbind until there is a change in AD
behaviour (see my previous mail for details) and my client refused to
modify its schema.
Good point: no change needed on file's rights
Bad point: they need a process to give new users some UID/GID. They add a
process but it was for Centrify, this process had to be changed.
As I wasn't able to use winbind I finally made that working using SSSD,
thanks to Samba which can work using "security = ads" and SSSD to
produce
UNIX users from AD (using RFC2307 attributes or anything else)
But the point was also to simplify their process, so this proposition was
finally refused.
- changing UID/GID: by usage of idmap-rid UID/GID are stable, they are
built using MS user's RID + start of domain range in "idmap config AD :
range". As RID are stable (as long as you don't destroy a user object
to
recreate a new one) we get UNIX user without changing anything, without the
need of a specific process when creating new user in AD.
Very simple, stable, wonderful : )
This has a very bad point when there is a big amount of files/directories
with already attributed rights with old UID/GID: all files and directories
rights must be changed.
Fortunately the two file servers are not using the same storage, old files
have to be copied from old filers to a new one. And here is the solution of
this huge problem of file's rights: RSYNC. By default rsync, when creating
file on destination side, attribute rights according to user/group name and
not UID/GID, so doing a simple rsync of old data store to the new one using
rsync solved the rights issue.
And winbind using idmap-rid gave us a stable and very easy to use way to
manage UID/GID.
Sorry for all that blabla, I felt like it could be interesting to share
that.
Cheers,
mathias
2017-08-03 14:53 GMT+02:00 mathias dufresne <infractory at gmail.com>:
>
>
> 2017-07-27 16:33 GMT+02:00 mathias dufresne <infractory at
gmail.com>:
>
>>
>>
>> 2017-07-27 15:14 GMT+02:00 Rowland Penny via samba <samba at
lists.samba.org
>> >:
>>
>>> On Thu, 27 Jul 2017 08:51:52 +0100
>>> Rowland Penny via samba <samba at lists.samba.org> wrote:
>>>
>>> > On Thu, 27 Jul 2017 08:36:51 +0100
>>> > Rowland Penny via samba <samba at lists.samba.org>
wrote:
>>> >
>>> > >
>>> > > I will have a look at the provision code for the Samba DC
to see
>>> > > what it actually does when you use
'--use-rfc2307', if it just adds
>>> > > 'ypServ30.ldif', I will setup a test domain
without '--use-rfc2307'
>>> > > and see what happens ;-)
>>> > >
>>> > > Rowland
>>> > >
>>> >
>>> > OK, '--use-rfc2307' adds 'idmap_ldb:use rfc2307 =
yes' to smb.conf on
>>> > the DC and then adds 'ypServ30.ldif'. As far as I am
aware, nothing
>>> > actually uses anything in 'ypServ30.ldif'.
>>> >
>>> > I will set up a new domain and see what happens.
>>> >
>>> > Rowland
>>> >
>>> >
>>>
>>> OK, I can now confirm that you do not need '--use-rfc2307'
to use the
>>> winbind 'ad' backend on a Unix domain member.
>>>
>>> You do need 'idmap_ldb:use rfc2307 = yes' in the smb.conf
on a DC to
>>> use uidNumber & gidNumber attributes on the DC.
>>>
>>> You will not be able to use ADUC without '--use-rfc2307'
>>>
>>
>> Nice, thank you for testing. I'll try that next days to first be
sure of
>> the winbind client configuration.
>> Then I will have to test the working configuration against MS AD as it
is
>> MS AD my client use. It won't be my client too long...
>>
>
> Hi all,
>
> I'm digging up that subject as I finally was able to find time to dig
into
> the subject.
>
> So I first configure a file server using Winbind to retrieve user from AD
> using RFC2307.
>
> The tests :
> Initially that file server was joined to a Samba AD domain with RFC2307
> set up on DC (--with-rfc2307 during provision).
> No surprise, it worked.
>
> Then I removed RFC2307 using ldapmodify to delete 55 entries added by
> ypServ30.ldif which is the file used to add RFC2307 in Samba when it was
> provisioned without --with-rfc2307 (as described there:
> https://wiki.samba.org/index.php/Setting_up_RFC2307_in_AD#
> Installing_the_NIS_Extensions).
> Here again, after "net ads leave" then a join into that domain,
winbind
> was able to retrieve AD user using RFC2307 LDAP attributes, as long as I
> kept into into DC's smb.conf the following line as mentioned in
previous
> mail by Rowland the 27th of July:
> idmap_ldb:use rfc2307 = yes
>
> As I wasn't too sure about this modification (ldapmodify to delete
> entries) I tried using a brand new Samba AD domain provioned without usage
> of --with-rfc2307.
> Again, it worked, as long as the "idmap_ldb:use rfc2307 = yes"
xwas
> present in DC's smb.conf
>
> And as soon as "idmap_ldb:use rfc2307 = yes" was commented on DC
side,
> winbind on client side stopped working.
>
> Finally I removed that Samba file server from the Samba AD domain to join
> it to the MS AD domain of my client. This is a MS AD without support for
> RFC2307 configured.
> And Winbind was never able to generate UNIX user.
> wbinfo -n user gave user's SID
> wbinfo -S <user's SID> gave user's uidNumber (as we are
dealing with
> RFC2307 attributes, using idmap-ad)
>
> But wbinfo -i user didn't worked.
>
> wbinfo -i user
> failed to call wbcGetpwnam: WBC_ERR_DOMAIN_NOT_FOUND
> Could not get info for user user
>
> So usage of "idmap_ldb:use rfc2307 = yes" on DC side modifies
Samba AD
> behaviour enough for it differs from standard MS AD (nothing to wonder
> about in fact) but as Samba AD is not behaving like standard MS AD we
can't
> write winbind, using idmap-ad, can retrieve user from standard AD without
> RFC2307 configured, as this works only against Samba AD with a modified
> smb.conf.
>
> To write it differently winbind, using idmap-ad, can't retrieve user
from
> standard AD (MS AD not modified or Samba AD without "idmap_ldb:use
rfc2307
> = yes").
>
>
>>
>>
>>>
>>> Rowland
>>>
>>> --
>>> To unsubscribe from this list go to the following URL and read the
>>> instructions: https://lists.samba.org/mailman/options/samba
>>>
>>
>>
>