Re: [Samba] Restricting AD group logging on to Servers
- Date: Sat, 2 Dec 2017 20:08:31 -0000
- From: Roy Eastwood via samba <samba@xxxxxxxxxxxxxxx>
- Subject: Re: [Samba] Restricting AD group logging on to Servers
> > > Just one thing on that. Remember that this is not checked by SSH
> > > for authorized_keys based logins, it is run on the password
> > > checking path only. As long as they can't add such keys (no home
> > > dir) that is fine, but just be aware.
> > >
> > > I take it you have set a template shell and that is why you have
> > > access at all?
> > >
> > > Thanks,
> > >
> > > Andrew Bartlett
> > >
> > Thanks for pointing this out - I hadn't realised that. Yes I have
> > set a template in smb.conf for shell and home dir on the DCs but use
> > the unix attributes in AD for member servers. So to prevent such
> > logons, I should not set the home dir template or should I set it
> > to /dev/null or similar non-existent dir?
> > Thanks,
> > Roy
> I think Andrew has thrown you a curved ball here. By default on a DC,
> the logon shell is /bin/false and the homedirectory is '/home/%D/%U.
> That is, no users can log in, but if they could, they would get a
> homedir in /home/DOMAIN/username. So, as far as a DC is concerned, if
> you want anybody to logon, you must change the template shell
> parameter, but this would allow any user to logon. If you change the
> home dir template, this will also be used for all users, so if one
> group cannot logon, no one can logon.
> Your way of only allowing members of one group to logon is probably the
> only way to go. If a user doesn't have a home dir created they cannot
> logon and if they cannot logon, they will not get a home dir created,
> so there will be nowhere to store any ssh keys.
Thanks for clarifying that. However if I set the template homedir in smb.conf to /dev/null the user can still log on, and an error message is displayed, but the user is left at the root of the filing system (/). Maybe I have some setting incorrect? So I did some tests.
1) I set up a test user. This user is not a member of linuxadmins, so should not be able to log on to the servers using ssh (or at the console).
2) Set the users unix home directory to be the same as in AD for windows.
3) Logged on to a Windows computer using the test user's credentials.
4) Used PuttyGen to generate public and private keys for use with ssh.
5) Created the folder .ssh in the user's home folder on the server.
6) copied the public key to the authorized_keys file in the user's .ssh folder.
I found I was able to log on to the server with ssh using the keys! The solution therefore is to ensure the user doesn't have a (unix) home folder (or one that's inaccessible to the user from the network) as Andrew suggests. Along with the required group membership should ensure only those authorised to connect will be able to do so.
Thanks again to Andrew and Rowland. I think I understand it now! ;-)
To unsubscribe from this list go to the following URL and read the