[Samba] distributing samba users to the local systems

[Xen]

Rowland penny schreef op 14-07-2016 9:39:

> What you seem to be describing is a 'workgroup', the great-grandfather 
> of AD :-)
> If you only have a few computers that are close together, then yes, it
> probably will do what you require. If you have a lot of computers (and
> by this I mean more than about 12), it becomes a nightmare, every new
> user has to be added to every computer, then added to the required
> groups. This soon became apparent to MS, who then came up with the NT4
> style PDC, this then lead to AD. You do not need to have windows
> computers to use AD, you can use it with Unix computers and it will
> give you just one place of administration, you just need to set Samba
> up correctly, for this, see the Samba wiki.

I know. But this is a disconnected system; I require users on the local 
system for all the files on the local system.

In a sense the situation is this:

- all files that have central ownership and require central directory to 
know about their owners, should not be on the local computer
- all files that do not have central ownership, can be on the local 
computer.

By the way, I meant that I duplicate the users with LDAP on the server, 
not on the local computers.

So I have two distinct sets of users: local and central. It's just that 
I prefer local for SSH login (on the server).

I mean regular unix users instead of just LDAP users. One reason is 
obviously that my Synology puts the home directory of LDAP users in
"/volume1/home/@LH-DISKSTATION.LOCAL/61/<username>" or something of the 
kind.

That also implies that if I want to use regular home directories (the 
//server/home share) I must not currently use LDAP users for it. 
Moreover...

If I intend to have a public share that is likened to those of the other 
shares with regular users, and if I want this public share to "hardlink" 
some files from other shares, then the users are getting mixed.

But not doing that is troublesome because then my SSH user etc. won't be 
able to create files that are readable by others. So now the regular 
"public" share really requires a local (unix) user on the server, (not 
on the client) whereas the shares that actually do have other users 
contributing stuff will need LDAP users.

It's not all that pretty but.... it works for now. The issue is only 
duplicating local users into LDAP or vice versa (for the server, not the 
clients).

That is not something that would be hard to automate, in essence.


Meaning

//server/public  ---> really requires local users on the server
//server/hub     ---> really requires LDAP users on the server

Thus

//server/public  <--- login with unix user
//server/hub     <--- login with LDAP user

And it works.

//server/public  ---> don't allow ownership information to reach the 
client (use nounix)
//server/hub     ---> do allow ownership information to reach the 
client.

This way no local user on the server (unix users) will ever have any 
impact on the client systems apart from the fact that they need 2 sets 
of credentials files (or a domain flag for the hub login).

The credentials are the same, the /public login just doesn't require a 
"domain" whereas the hub login does (to specify LDAP users).

This works with Samba as default the way it is installed :). It was a 
pleasant surprise to find that using a domain instantly caused it to use 
LDAP for authentication.


I have only one issue now on the clients.

When LDAP is live, and when switching users, they will see all the LDAP 
users as well (passwd database) but they cannot login to it (auth 
database).

LDAP users should not be allowed to login to local systems really. I do 
not know yet of a way to filter this.

Maybe set a login shell variable in the LDAP?

http://www.tldp.org/HOWTO/archived/LDAP-Implementation-HOWTO/schemas.html

PosixAccount doesn't really specify a shell. Well, actually there is a 
loginShell value in the LDAP database.

And putting it to /bin/false indeed prevents the account from being 
listed :).

Now that I think about it, perhaps having an admin account on the system 
would be in order.

Of course I can enable the root user.

Regardless this is not a user friendly thing and not meant for login. 
Although at the same time, it is also not possible to have some Admin 
user with Root rights.

The only thing you could possibly do is remove the regular user from 
sudo access, but that is also not very convenient, seeing the number of 
times you actually do need root access, even as a regular user.

It is not really acceptable to not be able to install packages, or 
change simple things. Again, the root/user dichotomy in Linux bites me.

The user can do so little and the root can do so much that the user 
needs to be root most of the time for doing anything. Stuff like the 
"staff" group is hardly used on default linux systems, or at all.

At most you can grant a non-privileged user access to /usr/local, and 
that's about it.

There is no per-user package install system or anything of the kind, 
although Java applications usually go that route.

More work. Always more work ;-). The system is so bad, that everything 
requires More Work.

Anyway, thank you for your attention ;-).

And putting me to work like this :(. But at least the fake login problem 
is now solved, for now.

I just want a second user with Admin rights though. But I can only 
create a duplicate of the current user in terms of access rights. "Root" 
is not a user friendly nomenclature. We'd need a root user that is 
called Admin ;-).

But this is hardly possible. Not unless I apply one big long ACL to all 
of the files in the system.

recursively add u:admin:rwx to all of the files in the system. Then add 
inherit rights as well.