Assigning restricted admin role
 

Is it possible to give a user restricted administrative rights to only unlock other user accounts that get locked out? If so, how is this done?

IT can depend on a number of things - mostly how the user accounts are administered. There is NIS, LDAP, Kerberos + LDAP/NIS, local accounts only...

In some cases, a program specifically designed to just unlock a specific class of accounts (determined by UID? or whatever) can be accessed via sudo, which can have the specific command option limited to specific users.

In other cases, it requires access to remote databases... and the database support itself may be able to provide subsets.

It also depends on whether that same user is also supposed to be able to change the password (a locked account is just a flag... and clearing it doesn't necessarily change the password, and changing a password doesn't necessarily unlock the account).

So "how is this done" has lots of different answers.

Hi & Welcome to Linux Questions.


AFAIK only the Administrator (root user) can do that.
http://www.cyberciti.biz/faq/linux-locking-an-account/

The Administrator can also give other users Read, Write and Executable permissions and Configure a user account to use a restricted shell.

http://www.cyberciti.biz/tips/linux-...with-rssh.html

Is the account locked due to several failed log in attempts?
If so see here:

http://superuser.com/questions/58921...x-user-account
http://sharadchhetri.com/2013/12/13/...ount-in-linux/

It is possible for root to delegate that. A number of user administration tools are around. The problem is that there are a number of ways user accounts can be setup - some local, most are remote.

Kerberos has ways of locking user accounts - and being able to manipulate the kerberos database is one of the ways to do that - using various kerberos privilege flags to do so.

Thanks jpollard-;)

I found the documentation on Kerberos on the RH website.
https://access.redhat.com/documentat..._Kerberos.html

Is the local user generally on the client?

Not necessarily.

A user may obtain credentials on an untrusted system with kerberos clients... The credentials have a limited lifetime, usually 8 to 10 hours (as decided by the KDC administrators). That untrusted system will have its own login requirements.

A trusted system will require the use to obtain credentials during a login. The basic procedure is that the login tool performs a kinit to obtain user credentials, then it uses those credentials to obtain a service ticket for the trusted system. It then uses the host credential already present on the trusted system to validate the credential. After the service credential is validated, the user is then authorized by the system using what methods it has been configured. "what methods" can be the basic UNIX authorization (user account exists, authorized storage access, and any local time restrictions), or remote (LDAP/NIS/... record exists, users storage matches and exists...). It roughly corresponds to an AD login in windows.

One of the things that is possible is that the users credentials may be accepted by servers for different periods.

One of the places I worked had the servers configured to only accept user credentials if they were less than 15 minutes old if the connection was from an "untrusted" network. "untrusted" here means a network not under control by the administrators (they could just reject the credentials entirely... but a lot of the users were remote, and the network those users were on happened to be educational, or home networks - thus "untrusted"). If the credential was from a trusted client then the credential would be given 10 hours. If the credential came from an internal server, it might be trusted for 24 hours.

After the "trust" period had expired, the user is locked out until they obtain new credentials.

Trust of a client involved giving that client system a host keytab, and that required the client to be managed/controlled by the organization issuing the keytab. Thus servers within the site were trusted, but that trust could also be given to workstations also managed by the site.

Good information:-
I'll have to read the Documentation to understand the details fully; Thanks.

bob4:
Are you on a server for the Enterprise?

If so you should utilize jpollard council and consider using Kerberos.