On 01/04/2023 22:48, Gary Dale via samba wrote:> There used to be other users and my wife may still go back to using a > computer (she prefers her phone and tablet now). This also served as a > test bed for a business domain until a few months ago. > > And don't mistake one user for one computer. I have several Windows VMs, > not to mention multiple Linux boxes. The Windows VMs aren't used often > so there is some benefit to having them at least do a central login so I > only need one password. > > ?I've been experimenting with getting AD to handle the authentication > intermittently for over a decade but never got it to work. > > I've also had enough experience with Windows workgroup sharing to > realize that is not an attractive option. Windows machines really want > to be part of a domain, even if M$ allows them to stand alone.Workgroups had their day over 20 years ago, once you got over 10 users, they became a pain, which is why domains came about. The first incantation, NT4, was okay but had its limitations and these were mostly covered by AD in the Win2k domains and they have gone from there. Just about the only Windows that isn't expected to be part of a domain is the home version and that is only because they do not have the domain portions and are supposed to be virtually the only computer. If you are going to run Samba as an AD DC, then you have to run it correctly and hopefully follow the recommendations. You have said that you are running Windows in VM's, can I suggest you run Samba as a Unix domain member in a VM and just use your Samba AD DC for authentication. Rowland
On 2023-04-01 18:17, Rowland Penny via samba wrote:> > > On 01/04/2023 22:48, Gary Dale via samba wrote: > >> There used to be other users and my wife may still go back to using a >> computer (she prefers her phone and tablet now). This also served as >> a test bed for a business domain until a few months ago. >> >> And don't mistake one user for one computer. I have several Windows >> VMs, not to mention multiple Linux boxes. The Windows VMs aren't used >> often so there is some benefit to having them at least do a central >> login so I only need one password. >> >> ??I've been experimenting with getting AD to handle the >> authentication intermittently for over a decade but never got it to >> work. >> >> I've also had enough experience with Windows workgroup sharing to >> realize that is not an attractive option. Windows machines really >> want to be part of a domain, even if M$ allows them to stand alone. > > > Workgroups had their day over 20 years ago, once you got over 10 > users, they became a pain, which is why domains came about. The first > incantation, NT4, was okay but had its limitations and these were > mostly covered by AD in the Win2k domains and they have gone from there. > Just about the only Windows that isn't expected to be part of a domain > is the home version and that is only because they do not have the > domain portions and are supposed to be virtually the only computer.Agreed. Even people with two identical Windows computers find sharing things is not something you can rely or easily fix when it goes wrong. One other reason for running a domain is roaming profiles - which makes backing up users really easy - just back up the roaming profile on the server. Nothing extra to run on the client machines - they don't even have to be connected or powered on.> > If you are going to run Samba as an AD DC, then you have to run it > correctly and hopefully follow the recommendations. You have said that > you are running Windows in VM's, can I suggest you run Samba as a Unix > domain member in a VM and just use your Samba AD DC for authentication.I could, but that seems like overkill. A complete second (virtually identical) system to administer and update just to hive off the authentication task.
02.04.2023 01:17, Rowland Penny via samba ?????: ..> If you are going to run Samba as an AD DC, then you have to run it correctly and hopefully follow the recommendations. You have said that you are > running Windows in VM's, can I suggest you run Samba as a Unix domain member in a VM and just use your Samba AD DC for authentication.It is more practical to run the AD-DC in a VM (or a container) and regular file server on the usual system. You don't need to reconfigure the DC often, but it is essential for it to be running all the time. Also a DC alone is self-contained, the only share it exports - sysvol - can be made a part of it. So it is like install and let it do the trick, don't touch it. A VM can easily be migrated to another physical machine too. On the other hand, on a regular fileserver, you can add/remove shares, reconfigure storage, use large storage, and generally more often interact with whole system. There's an interesting approach to running an application within a systemd-nspawn container off the system root, it fits this usage very nicely and there's no need to administer extra system. Unfortunately systemd basically stepped away from ability to spawn containers off the system root, they've added several checks which prevent this usage. Maybe there's some other simple way to spawn an app within its own network and filesystem namespace which can be used here. /mjt