Can you set Centrify agent so that login precedence has users login using their local userid?
04-26-2017 09:52 AM
In this environment, they are installing the centrify agent first, and then analyzing the local userids to see which ones need to be transferred to Centrify control and which ones need to be removed. So, they wish to have the users still be able to log in with their local userids instead of their active directory ids until after the analysis is done.
Is there any way to set the centrify agent so that it allows this action instead of forcing the user to use their Active directory userid?
I read the Centrify Unix Configuration guide, and though I felt like I was close, I am not there....
Any suggestion are appreciated.
Solved! Go to Solution.
04-26-2017 10:02 AM
Several ways to do this:
- Simpler: You can add the users in question to the /etc/centrifydc/users.ignore file in the target systems. This way the users will be effectively "ignored" by adclient. You have to run an adreload for this to be effective. This parameter can be updated without touching all systems using Centrify group policy or using DevOps
- Slightly more complex: You could switch the order the name service switch locates the users in the /etc/nsswitch.conf e.g. instead of:
passwd: centrifydc filesYou can make it
passwd: files centrifydcThis way any NSS-enabled app will look in the local files first for the user instead of AD using Centrify. This requires that you disable autoedit for NSS (adclient.autoedit.nss).
Active Directory level
- A bit more elegant: You can also not assign a role to the users in question (or not give them a UNIX profile), this effectively will make them invisible to the system. This way when they are ready you just add them to the AD group that grants them a role or gives them a UNIX identity.
04-26-2017 10:23 AM
Thank you for responding so quickly to my question.
Being from a Unix background, I understand the simpler solution. Could you elaborate more on the Active Directory Level solution?
04-28-2017 12:20 PM
Sorry for the delay on coming back to this thread.
Here are some basics.
In order for an AD user to have access to a system in a Centrify zone, they need 2 things:
- A UNIX identity (or profile) - this means that in the Centrify zone in AD, they have populated their login, UID, GID, GECOS, home shell and primary group.
- A Role assigned to them - this role most contain at a minimum a PAM right that allows them to access based on the security of their role (some people only need SSH access, others sftp or mongod, while sysadmins need all PAM-enabled apps plus the console)
If any of these are missing, the user won't be available to the system (therefore, their only option would be to log in with their local credentials).
Most of the times, UNIX-enablement or Role assignments are performed by way of AD group membership; so you can have a set of users that are migrated that have a complete set of requirements, and a subset (the ones yet to migrate) that may be missing one or the other pre-requisite.
As you greenlight users, all you need to do is add them to the group(s) that will grant them their pre-requisites to log in with their AD credentials. In the meantime, those who aren't can just sign-in with local credentials.
I hope this makes sense.