System Administration
cancel
Showing results for 
Search instead for 
Did you mean: 

How I do specify a different shell for users in Winbind auth login

Arumugavel_P
Occasional Advisor

How I do specify a different shell for users in Winbind auth login

Hi,

 

I am using winbind/ldap uathendication on my linux boxes from Windows AD.

It works fine with termplate shell.

 

template shell = /bin/bash

 

which is defined in smb.conf. So all ldap users are getting assigned the bash shell on my linux.

 

But now I have somes users (ftp users) are assigned to restricted shell (rssh).

Now how can I migrate them into AD specifying this specific shell rssh for these ftp users?

 

is there any way to change the attribute in AD (windows)?

 

Please help me.

 

OS: SUSE 11

samba-winbind-3.4.3-1.32.1

 

Thanks in advance.

 

Regards,

Vel

2 REPLIES
Fred Abell
Occasional Advisor

Re: How I do specify a different shell for users in Winbind auth login

You could just let the user change his shell. Typing 'csh' puts a user in C shell. 'Exit' reverts back to the bash shell.

Matti_Kurkela
Honored Contributor

Re: How I do specify a different shell for users in Winbind auth login

As the question included key concepts of "ftp user" and "restricted shell", I don't think these users are supposed to be allowed to change their own shells.

 

The problem of winbind is that it is essentially designed for on-the-fly translation of Windows domain user accounts to generic, one-size-fits-all Unix/Linux accounts. In your case, you have Linux accounts with special attributes that have no direct equivalent in Windows environment, so winbind has no way to know about those attributes.

 

What is in the "passwd" line of your /etc/nsswitch.conf?

Is it

a) something like:

passwd: files winbind

 or

b) something like:

passwd: files ldap

 

If a), then as far as I know, the only way would be to have the user to log in once, then use the "id" command to see which UID/GID numbers winbind assigned to the user, and then write a regular local /etc/passwd line for that user with the restricted shell applied, so that it will match the information provided by winbind, but replace the winbind template shell with a restricted shell.

 

If you're using the default "idmap backend" smb.conf setting, you will then have to repeat this on every host the FTP user can log into, i.e. the convenience of having the user's password changeable via AD is outweighed by a lot of extra work in creating/deleting/modifying the FTP users. In this case, I would recommend leaving the FTP users configured as local users.

 

If you're using a shared idmap backend ("idmap backend = ldap" or similar, with all the other settings it requires), then the complex procedure just might be tolerable if there are a small number of FTP servers. But it's still a crude hack and I would not recommend this.

 

In either case, you will still have to remember to configure *all* your servers to disallow normal logins to the FTP user accounts (e.g. make sure all non-FTP access is denied for the AD group that contains the FTP users): if you forget it when setting up one server, that server will allow the FTP users to log in as regular users, which may be a security issue.

 

If b), you probably already have either a RFC2307 or Windows ServicesForUnix schema extension in your AD. That extension would allow AD to control all the Unix/Linux-specific attributes of each user: among other things, it would allow you to specify a restricted shell for certain user(s).

 

If you use b)-style configuration, you might even want to pre-assign Unix/Linux UID/GID numbers for all your AD users and then use "idmap backend = ad" (see "man idmap_ad" for more information). That would give you an uniform set of UID/GID numbers on all hosts, which can be nice in many situations.

 

However, the b)-style configuration requires more initial set-up than just using winbind: you must set up the schema extension on the AD, and configure a real LDAP client on each Linux host. (For authentication purposes, AD is essentially a special form of LDAP.)

MK