samba - Dec 2023 - Joining Windows 10 Domain Member to Samba AD/DC

On Sun Dec 10 05:49:43 2023 Rowland Penny via samba <samba at
lists.samba.org> wrote:

(regarding idmap backends)
> The 'ad' backend:
> This is only required if you need the rfc2307 attributes for different
> Unix home directories and login shells. It also requires that you use
> and populate the rfc2307 uidNumber & gidNumber attributes for users
&
> groups that you require to be visible on Unix.
> 
> The 'rid' backend:
> This backend does not require any alterations to AD. It calculates the
> user & group Unix IDs from the user or group RID. If you use the same
> basic smb.conf on all Samba Unix domain members, you will always get
> the same Unix ID. You are limited to Unix home directory path and login
> shell which by default are set to /home/%D/%U and /bin/false , though
> they can be changed by setting the relevant parameters in smb.conf ,
> for instance
Now that I've successfully provisioned a new Samba AD/DC, I need to join
Windows
10 workstations to the new domain. A couple of questions:

1) I've provisioned with the SAMBA_INTERNAL DNS backend. In our current
domain,
workstations are allocated static IPs and so are devices like printers. Do I
assume correctly that dhcpd will continue to work on the new DC? 

Will the SAMBA_INTERNAL DNS pick up new devices I add to /etc/dhcpd.conf?

I used to be able to remove obsolete devices by editing the zome files.  Can I
do something similar with the SAMBA_INTERNAL DNS backend?

2) I used the 'rid' backend to join a Linux domain member to a Windows
DC. Now
I'm doing the reverse, joining a Windows 10 domain member to the new Samba
DC.

I did provision the Samba DC with --use-rfc2307. Does that mean I should join
with the 'ad' backend for the new Windows member?

If so, must I then "populate the rfc2307 uidNumber & gidNumber
attributes for
users & groups that [I] require to be visible on Unix"? The old/current
DC does
have uid/gidNumbers for users and groups. 

The old/current system had two samba shares accessible by domain users using
their domain credentials: "Redirected Folders" on the AD/DC, and a
shared folder
shared by a Linux domain member / file server.  Both directories had the domain
uid and gid number set on the files.  I'll be doing these shares for the new
domain (except I may not put the "Redirected Folders' on the domain
controller).

When setting up the old/current DC, I added each user to the domain using the
Windows "Active Directory Computers and Users" Administrative tool.
With that, I
entered both uidNumber and gidNumber for each user. This time, I'm going to
try
using the ForensiT tool to migrate the users (which may not work with Samba, but
we'll see).

In short, does what I want to do with users, Samba file server shares, etc. 
mean I should use the 'ad' backend instead of the 'rid' backend
when joining
Windows domain members? Note that actual home directories and login shells are
irrelevant as the domain users are only on Windows and there are no domain users
accessing from the Linux members (except for the administrator). 

Thanks --Mark

On Mon, 11 Dec 2023 07:45:04 -0500
Mark Foley via samba <samba at lists.samba.org> wrote:
> On Sun Dec 10 05:49:43 2023 Rowland Penny via samba
> <samba at lists.samba.org> wrote:
> 
> (regarding idmap backends)
> 
> > The 'ad' backend:
> > This is only required if you need the rfc2307 attributes for
> > different Unix home directories and login shells. It also requires
> > that you use and populate the rfc2307 uidNumber & gidNumber
> > attributes for users & groups that you require to be visible on
> > Unix.
> > 
> > The 'rid' backend:
> > This backend does not require any alterations to AD. It calculates
> > the user & group Unix IDs from the user or group RID. If you use
> > the same basic smb.conf on all Samba Unix domain members, you will
> > always get the same Unix ID. You are limited to Unix home directory
> > path and login shell which by default are set to /home/%D/%U and
> > /bin/false , though they can be changed by setting the relevant
> > parameters in smb.conf , for instance
> 
> Now that I've successfully provisioned a new Samba AD/DC, I need to
> join Windows 10 workstations to the new domain. A couple of questions:
> 
> 1) I've provisioned with the SAMBA_INTERNAL DNS backend. In our
> current domain, workstations are allocated static IPs and so are
> devices like printers. Do I assume correctly that dhcpd will continue
> to work on the new DC? 
> 
> Will the SAMBA_INTERNAL DNS pick up new devices I add to
> /etc/dhcpd.conf?
> 
> I used to be able to remove obsolete devices by editing the zome
> files.  Can I do something similar with the SAMBA_INTERNAL DNS
> backend?
> 
> 2) I used the 'rid' backend to join a Linux domain member to a
> Windows DC. Now I'm doing the reverse, joining a Windows 10 domain
> member to the new Samba DC. 
> 
> I did provision the Samba DC with --use-rfc2307. Does that mean I
> should join with the 'ad' backend for the new Windows member?
> 
> If so, must I then "populate the rfc2307 uidNumber & gidNumber
> attributes for users & groups that [I] require to be visible on
> Unix"? The old/current DC does have uid/gidNumbers for users and
> groups. 
> 
> The old/current system had two samba shares accessible by domain
> users using their domain credentials: "Redirected Folders" on the
> AD/DC, and a shared folder shared by a Linux domain member / file
> server.  Both directories had the domain uid and gid number set on
> the files.  I'll be doing these shares for the new domain (except I
> may not put the "Redirected Folders' on the domain controller). 
> 
> When setting up the old/current DC, I added each user to the domain
> using the Windows "Active Directory Computers and Users"
> Administrative tool. With that, I entered both uidNumber and
> gidNumber for each user. This time, I'm going to try using the
> ForensiT tool to migrate the users (which may not work with Samba,
> but we'll see).
> 
> In short, does what I want to do with users, Samba file server
> shares, etc. mean I should use the 'ad' backend instead of the
'rid'
> backend when joining Windows domain members? Note that actual home
> directories and login shells are irrelevant as the domain users are
> only on Windows and there are no domain users accessing from the
> Linux members (except for the administrator). 
> 
> Thanks --Mark
> 
When you provision with the '--use-rfc2307' switch, all that happens is
that the ypServ30.ldif is added to AD, this just provides the framework
that IDMU used to provide the Unix_Attributes tabs on ADUC, but the
last Windows version that worked on was Windows 7. All the rfc2307
attributes are a standard part of the AD schema.

Now lets talk about mapping AD users to Unix users. There are several
ways that Samba can do this, which we discussed earlier. However, lets
briefly go over them again:

Windows to Windows, there is no mapping, the objects SID is used.

On a Samba AD DC, there are two options:
The built-in idmap_ldb that uses numbers in the 3000000 range and are
allocated on a first come basis i.e. the first user or group gets
'3000000', the next '3000001' and so on.

These '3000000' numbers can be overridden by giving AD users &
groups a
uidNumber or gidNumber attribute, in which case you get to choose the
range. You must not that you will also require 'idmap_ldb:use rfc2307
= yes' being set in the DCs smb.conf file.

On Unix domain members, there are a number of idmap backends, but the
most used are the 'ad', 'rid' and 'autorid'

If you use the 'ad' backend, then you must add uidNumber & gidNumber
attributes to AD and set the 'DOMAIN' range in smb.conf to match the
range you have used, any of these attributes that contain IDs outside
the range you set in smb.conf will be ignored. The main benefit of
using the 'ad' backend is that you can set different Unix home
directories and login shells per user.

If you use the 'rid' or 'autorid' backend, then the Unix IDs are
calculated for you, you need add nothing to AD and any uidNumber &
gidNumber attributes in AD will be ignored  You also cannot set Unix
home directories or login shell per user, it is strictly the same for
everyone on that Unix domain member.

If you are just using the DCs for authentication (as it seems you are),
then it sounds like there is nothing to be gained by using the 'ad'
backend.

Rowland