Rowland Penny
2023-Dec-11 13:24 UTC
[Samba] Joining Windows 10 Domain Member to Samba AD/DC
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
I'm attempting to join a Window 10 computer as a domain member to a Samba AC/DC. I'm trying to use a tool from ForensiT https://www.forensit.com called Transwiz. This tool is supposed to join the Windows computer to the domain AND migrate user profiles from a different domain to the new domain. I created the domain user on the DC using samba-tool. Then I ran transwiz on the Windows computer and answered the various questions as to domain name and user, and it began the process, but ended up with the error: "The following error occured attempting to connect to the domain hprs.locl: The RPC server is unavailable." I started rpc on the DC and tried again, but got the same error. Supposedly this tool does work with Samba DCs. Any idea what the the problem could be? It finds the DC just fine. Thanks --Mark