Rowland Penny <rpenny@???> wrote:

>> I think what Roland was getting at here is the number of users and
>> how they are dealt with makes a huge difference.
>>
>> At one extreme, you have 28 seats, each one of them has a user such
>> as "user1", and you can simply use /etc/passwd & /etc/shadow to
>> manage that single user one each seat. You could probably build one
>> software image and simply image all 28 machines with that one image.
>
> This would entail running Samba as a workgroup and, once you get past
> about 10 machines, it get unwieldy, you have to create the exact same
> users on every machine you want them to connect to and keep their
> passwords in sync. This can rapidly become a nightmare, this applies
> if you decide to go with NFS instead.

Indeed, but this scenario is for a fixed setup where the users (28 of them) are setup once and then there is no further user maintenance going forward. In such a scenario, there's little point in going for the complexity of setting up AD - as you say, a one-off setup of the users in Samba. The clients could potentially be configured to auto-login to the desktop (or training system) on boot so the users don't even need to know about users.
Easy for users, no security.

>> At the other extreme, every person has their own login and can use
>> any seat at any time (and there are hundreds or even thousands of
>> them) so that progress/results can be logged for each person. In this
>> case, you will really need a centralised user management such as
>> Roland described using Samba & AD. You could still image each machine
>> from one common image - but you'll need to do some post-imaging setup
>> to give each machine a unique set of identifiers etc for the AD to
>> work properly.
>
> If you run Samba as an AD DC and join the clients to this, you only
> have to create the users & groups once and the password is only stored
> in one place, the DC.

Exactly - for many users, and especially if the users are dynamic, then it's the only sane way to do it.

And it also means that each user has their own personal login & home directory so (if it isn't stored in a database that's part of the training system) there is somewhere for the system to store each users progress etc.

Which leads to another question ... Does the training system itself have a user directory etc ? This also has an impact on the solution chosen.

If the training system has a logon for each user and stores (eg) progress information in it's own database, then it makes little sense to also configure each user separately to the OS (eg using Samba & AD). Just setup the machines as above with a single user and manage users via the training system.
On the other hand, if the database (the schema, not just the DB engine) is "open" enough then it may be possible to use that as an authentication source - giving each user their own OS level login which is the same as the traingin system login, but using just the one database.

Many possibilities - the "best" for any setup depends on answers to these sorts of questions.