Need suggestions for managing users
-
snapon_admin
- Posts: 952
- Joined: Mon Jun 10, 2013 10:39 am
- Location: Kenosha, WI
- Contact:
Need suggestions for managing users
We're currently running XI 5.6.10 and using AD integration for our user access. Is there any way to automatically deactivate or even remove a user from our Nagios server if they've been removed from AD (i.e. they've left the company)? I'm trying to manage our users and remove access from the user accounts of employees that have either left the company or left the IT department, but i'm struggling with a best practice for this. I could have our server team put in a ticket and assign it to me whenever they make a user adjustment on Nagios, but that's a bit of a hasttle considering not every user ID they remove/modify will have had Nagios access in the first place. Just looking for some ideas/suggestions from other people that have had to manage user access in their environment.
Re: Need suggestions for managing users
I'm not sure of a quick and easy solution to this off the bat, but how about this... A script that is run as part of the termination/off-boarding process that calls the Nagios API. The script checks the API to see if the user exists in XI, if so, generate a random password for it, disable notifications, set read only, and disable the account.
Personally I go with the locking down of the account rather than delete, just in case there is some kind of information you might want to glean from what their Nagios account looks like, or could see, etc. I can't imagine what that would be, but having information is usually better than not having information. You can always straight up delete the account if you would rather not have the accounts hanging around at all.
The first drawback I see with this is a pretty big one in that I think in order to do this work, the API user would need to be an administrative user. Having the API key baked into a script that could potentially fall into the wrong hands is less than stellar. At that point you would have to look into making the script auto-notify when a member of the team who is responsible for running the script leaves, at which point it would throw a flag to whomever is running the script to create a ticket for you to create a new API key and give it to them to put in the script.
Which narrows down the hassle of you getting a ticket every time someone leaves the company, but makes the script more complex.
To swap that and keep the script simpler, but give you more hassle. The script could be for a read only user. It would only have the ability to check to see if the user existed in XI, and if so, it would auto create the ticket for you to lock down the user. Assuming that your ticketing system has an API that can be somewhat safely called from a script like this. If it does, then this could also be applied to the above solution, in the event that someone responsible for running the script leaves.
Personally I go with the locking down of the account rather than delete, just in case there is some kind of information you might want to glean from what their Nagios account looks like, or could see, etc. I can't imagine what that would be, but having information is usually better than not having information. You can always straight up delete the account if you would rather not have the accounts hanging around at all.
The first drawback I see with this is a pretty big one in that I think in order to do this work, the API user would need to be an administrative user. Having the API key baked into a script that could potentially fall into the wrong hands is less than stellar. At that point you would have to look into making the script auto-notify when a member of the team who is responsible for running the script leaves, at which point it would throw a flag to whomever is running the script to create a ticket for you to create a new API key and give it to them to put in the script.
Which narrows down the hassle of you getting a ticket every time someone leaves the company, but makes the script more complex.
To swap that and keep the script simpler, but give you more hassle. The script could be for a read only user. It would only have the ability to check to see if the user existed in XI, and if so, it would auto create the ticket for you to lock down the user. Assuming that your ticketing system has an API that can be somewhat safely called from a script like this. If it does, then this could also be applied to the above solution, in the event that someone responsible for running the script leaves.
As of May 25th, 2018, all communications with Nagios Enterprises and its employees are covered under our new Privacy Policy.
Be sure to check out our Knowledgebase for helpful articles and solutions!
Be sure to check out our Knowledgebase for helpful articles and solutions!