Nagios Support Forum

Using something like LikeWiseOpen.

I just wanted to post here that I was talking to someone else this week who said LDAP integration would be a requirement to even consider using Nagios XI. Sent a question about which specifics he's looking for.

<tyarusso> Say, regarding LDAP integration in Nagios XI as we talked about the other day, could you provide more details on what kinds of integration would be desired in your organization? For instance:
<tyarusso> A. Generating user accounts from data found in an LDAP server
<tyarusso> B. Authenticating against an LDAP server
<tyarusso> C. Both of the above
<tyarusso> D. Managing contact groups in LDAP
<tyarusso> E. Defining Nagios roles/permissions through LDAP groups
<tyarusso> F. Something else?
<Seveas> G. All of the above
<Seveas> but C. as very least

I'm in the evaluation stage of Nagios XI in my organization (roughly 1600 people, 1300 servers, ~800 TB storage), and I can also say that LDAP authentication is critical to my organization. The lack of LDAP integration is a serious detriment in our evaluation, to be honest.

The LDAP server that we use is ActiveDirectory, but we authenticate everything off it, including around 1,000 Linux servers and UNIXes. Management of LDAP user/roles/etc within Nagios XI itself is not required, as long as it can be done via the standard tools (AD Users and Computers MMC).

This topic interests me greatly. There are lots of generalizations be thrown around on this forum and I just need to understand better the terminology. By generalizations I mean that authentication is being done via LDAP using ActiveDirectory servers. This is vary open to interpretation and it would be much better if there were terms to describe what is meant. In the absence of terms it's necessary to explicitly depict what the exchanges are that take place.

By this statement alone I am able, with my limited understanding, able to discern these descriptions of workable solutions that are possible.

1. The simplest, IMHO, is that there is an LDAP relation that stores user:password hash:uid:gid:GEKOS:ect records and authentication is done against this information as though it were NIS or files/NSSWITCH.
2. A different schema that accomplishes basically the same functionality as 1, perhaps using clear text passwords or some other hash then DES/md5/sha1/ext.
3. Authentication is done against the LDAP service using the supplied credentials and if successful(perhaps with read or read/write access to a particular resource being a conditional requirement that the account must satisfy) then the login is allowed.

There are of course other possibility as we havn't even touched on integrating Kerbose for authorization and using LDAP for user to group/policy mapping. It seams if you wanted integration with MS Windows Workgroup user names and passwords that this is more where your focus might lye.

For my organization, it should be fairly straightforward ... we use Quest's Authentication Service (formerly Vintella's Authentication Service) to provide a single-sign-on structure for our enterprise. This allows the Linux servers to authenticate user/group policies off the AD tree, as well as other features such as pushing sudoers and hosts.{allow|deny} based on Organizational Unit (OU).

For our purposes, this means we can either auth to system or to AD directly.

I'm glad you guys are taking this seriously, when I suggested this previously I was not overally impressed with the initial response. http://support.nagios.com/forum/viewtopic.php?f=6&t=124

mmestnik wrote:This topic interests me greatly. There are lots of generalizations be thrown around on this forum and I just need to understand better the terminology.

What I would like:

• * Have all my admins use their AD account to login to Nagiso XI
  * I don't want to have to maintain another bunch of user accounts / passwords
  * Perhaps single sign on, I.E. when I am using my browser and go to the Nagios login page some sort of tick box that says "login using my current credentials of my windows account"
  * I only have a need for AD LDAP integration. Workgroup user accounts is not required.
  * Support for groups. So instead of adding a new user to AD and then going to XI and adding the user with specific permissions I would like to be able to add a user to AD, add that user to an AD group. That AD group has already been configured in XI with all the correct permissions. The user at this point can immediately log in.
  * Perhaps the ability to pull the users email address from AD so it knows your email address to send notifications to if required
  * The ability to specify the domain I am logging in from. Some other products that have AD integration require domain\username and this is extra typing not required. However I do understand large organisations out there might have multiple domains with trust relationships. So a)the ability to login with just a username and it uses the default domain you've specified OR b) login with a specific domain\username account if required.
  * Specifify the OU (or multuiple OU's) that contain the user accounts and groups you with wish to use for loggin in. This is more secure than XI having access to the whole AD (and might be more beneficial for larger AD's). Perhaps the option of a) the whole domain or b) specific OU's
  * I DO NOT want usernames to be case sensative. I don't care if the user logs in as UserLast1 or userlast1, only the password should be case sensative.

Please ask me to clarify anything here if I haven't explained myself properly.

Box293 wrote:I'm glad you guys are taking this seriously, when I suggested this previously I was not overally impressed with the initial response. http://support.nagios.com/forum/viewtopic.php?f=6&t=124

mmestnik wrote:This topic interests me greatly. There are lots of generalizations be thrown around on this forum and I just need to understand better the terminology.

What I would like:

• * Have all my admins use their AD account to login to Nagiso XI

This is just one of the generalizations that I find amusing. You are attempting to refer to the credentials supplied to the Windows login screen when this particular workgroup is selected by usually a pull down sometimes in an advanced section?

Cont. Box293 wrote:

• * I don't want to have to maintain another bunch of user accounts / passwords
  * Perhaps single sign on, I.E. when I am using my browser and go to the Nagios login page some sort of tick box that says "login using my current credentials of my windows account"

Your browser should already support this internally. What more are you expecting? What is it specifically about Kerberos/AD/LDAP that you are looking for? I can guess and I think I know what it is, but it's not vary useful unless you understand how it's working for you.

Cont. Box293 wrote:

• * I only have a need for AD LDAP integration. Workgroup user accounts is not required.

As I expected these are not the same, but what are they then? What is it in or about AD/LDAP that so needs to be integrated? The reason I was incline to believe that these are not the same is that there are tons of free(as in freedom) tools that work with this information that don't use AD or LDAP at all(see samba and tsclient). If it was that simple we would just ask you to create a file in a share and if we can call smbclient and download this file then the user has access to the file and then thus has access to NagiosXI as that user... No need to re-invent a better wheel.

Cont. Box293 wrote:

• * Support for groups. So instead of adding a new user to AD and then going to XI and adding the user with specific permissions I would like to be able to add a user to AD, add that user to an AD group. That AD group has already been configured in XI with all the correct permissions. The user at this point can immediately log in.

One issue that would need to be addressed here is that Nagios XI has a handful of settings that would need to be applied to these Users/Groups. It would be nice for you if these could exist in AD, can they? If they can then we'd need to define a strict schema to architect this against. If this won't work then XI would need to be programed to apply templates on it's end. Creating templates and then mapping them to users/groups in AD is doable, but it's bound to have problems initially.

Cont. Box293 wrote:

• * Perhaps the ability to pull the users email address from AD so it knows your email address to send notifications to if required.

That would also be nice, this is the biggest problem with using LDAP. It works just like MySQL or MS-SQL, some one creates a table and in doing so gives it a name. Afterwards all any one needs to do is use the name of the table, but this can't be programmed it needs to be either well documented or reverse engendered. Sadly that latter part is specifically forbidden by Microsoft. So until there is some more information about how AD works and is structured these endeavors are hopeless.

Cont. Box293 wrote:

• * The ability to specify the domain I am logging in from. Some other products that have AD integration require domain\username and this is extra typing not required. However I do understand large organisations out there might have multiple domains with trust relationships. So a)the ability to login with just a username and it uses the default domain you've specified OR b) login with a specific domain\username account if required.

This is trivial, we should be able to do this typing for you.

Cont. Box293 wrote:

• * Specify the OU (or multiple OU's) that contain the user accounts and groups you with wish to use for logging in. This is more secure than XI having access to the whole AD (and might be more beneficial for larger AD's). Perhaps the option of a) the whole domain or b) specific OU's

This is LDAP, but how does this apply to AD or Kerberos? This is where the most amount of information is needed.

Cont. Box293 wrote:

• * I DO NOT want usernames to be case sensitive. I don't care if the user logs in as UserLast1 or userlast1, only the password should be case sensitive.

There are a number of things that are case sensitive that don't have to be, but there are many that are sensitive and will always be. IMHO for the users it's better for either all or none... As my mother always says, "For a click is that left or right?" It wouldn't be vary nice to cause the user to think about how sloppy they can type every time they go to type something. The descent answer for our product is to never type sloppily. So as we may release a version where any input is accepted as valid regardless of how sloppy, it would never be something to advertise.

Cont. Box293 wrote:
Please ask me to clarify anything here if I haven't explained myself properly.

Some of your responses make me think that you may not have used Microsoft's Active Directory (AD) and may need some explaining.

AD is a database (refered to as a domain) of user accounts, computers, groups (and other objects).
A computer loaded with a Windows operating system can be made a member of the domain.
This then allows a user to logon to that computer (or any computer in the domain) with their active directory account.
When they do this they receive a security token that contains information such as what groups their user account is a member of.
When a user tries to access resources on other computers in the domain (like servers) their security token is used to validate their permission to that resource.
An example of this is if you had a server loaded with Microsoft ISA acting as a web proxy. When you set your web browser to use the ISA server as the web browsers proxy server you are not prompted for credentials as the ISA server authenticates you with the security token you already have.

Box293 wrote:* I only have a need for AD LDAP integration. Workgroup user accounts is not required.

A workgroup is different to a domain. A workgroup is nothing more than a collection of Windows computers. There is no central location of user accounts, computers, groups. If you want to connect from one computer to another computer (like a file share) you will need to have the user account created on both computers with the same password. If you changed the password on one computer you would need to manually change the password on the other computer. Any company using a workgroup as their computer / network model would not be a potential Nagios customer (IMHO).

Box293 wrote:What I would like:
* Have all my admins use their AD account to login to Nagiso XI
* Perhaps single sign on, I.E. when I am using my browser and go to the Nagios login page some sort of tick box that says "login using my current credentials of my windows account"

mmestnik wrote:This is just one of the generalizations that I find amusing. You are attempting to refer to the credentials supplied to the Windows login screen when this particular workgroup is selected by usually a pull down sometimes in an advanced section?

So what I am requesting here is that when the user goes to the Nagios XI logon screen, they could type in their existing AD username and password and Nagios XI will use it's AD integration to authenticate this user. An extension of this would be a tick box called "Logon using my current windows credentials" so the user would not even need to type anything at all. If you want to see this functionality in another product, the VMware vSphere client is a perfect example. When you open the client you are prompted for a vCenter server to connect to, a username and a password. There is also a tick box called "Use Windows session credentials".

Box293 wrote:* I don't want to have to maintain another bunch of user accounts / passwords

It might not seem like a big deal to have to create a user account for a new user on the Nagios XI server each time a new staff member comes along. However when you start to look at large corporations, it is not unusual to have 1000+ users and 50 accounts to administer the domain. When you start talking about 50 admin user accounts this management can get out of control and it is easy for "admin" accounts to be left active when an employee leaves the company and hence there is a security risk. For example, if Nagios XI was integrated with AD and an admin staff member was fired from the company, disabling the users admin account in AD would immediately stop that user from being able to access Nagios XI.

Box293 wrote:* Support for groups. So instead of adding a new user to AD and then going to XI and adding the user with specific permissions I would like to be able to add a user to AD, add that user to an AD group. That AD group has already been configured in XI with all the correct permissions. The user at this point can immediately log in.

I have seen this type of functionality in our SonicWALL Pro4100 firewall. We use the SonicWALL Global VPN Client (GVC) to allow users to remotely connect to our network. In the Active Directory userA is a member of RemoteGroupA and userB is a member of RemoteGroupB. On the SonicWALL device two groups exist, RemoteGroupA and RemoteGroupB. Each of these groups determine what network resources they have access to. When the user connects with the GVC it checks the Active Directory to see if the user is a member of RemoteGroupA or RemoteGroupB. If they are, then they are granted access. NOTE: On the SonicWALL Pro4100 there are no user accounts created, once the SonicWALL was configured for AD / LDAP integration, no additional configuration is required, all you need to do is add a user to either RemoteGroupA or RemoteGroupB in AD and they will be granted access the next time they logon using the GVC. Remove the user from the group and they no longer have the ability to logon with the GVC.

So this is the real benefit of having support for groups. I could have seperate groups in AD that reflect different security roles I have defined in Nagios XI. By simply adding or removing a user from a group I can instantly grant or revoke the type of access the user has to Nagios XI.

Box293 wrote:* Perhaps the ability to pull the users email address from AD so it knows your email address to send notifications to if required.

mmestnik wrote:So until there is some more information about how AD works and is structured these endeavors are hopeless.

My mistake here, I was not specific enough, what I should have said is: Perhaps the ability to pull the users Exhange Server 2007 email address from AD so it knows your email address to send notifications to if required.
Exchange server stores it's information about user account details (like an email address) in AD. Each object in AD has attributes that these values are stored in. When an Exchange server is used in AD, the users primary email address is stored in the attribute mail. In addition to this all email addresses that the user has (not uncommon to have two or three different addresses per user) is stored in the attribute proxyAddresses.

Alternatively, if Exchange server is not the organisations choice of email server, you can actually put the email address in any empty attribute field like pager, notes, mobile etc. The point I am making here is that in the Nagios XI AD integration module you could allow us [the end user admin] to specify what AD attribute we have used to store the users email address. This allows you to provide a functionalilty of pulling an email address from AD but being flexible enough to suit many different environments without being too strict.

Once again, the purpose of pulling the email address from AD removes an administrative overhead, if I don't need to manually type it into Nagios XI and it can be automatically pulled from AD that is great. If a user changed their name (like when getting married) then their new email address would be automatically updated without any additional administrative overhead.

Box293 wrote:* Specify the OU (or multiple OU's) that contain the user accounts and groups you with wish to use for logging in.

mmestnik wrote:This is LDAP, but how does this apply to AD or Kerberos? This is where the most amount of information is needed.

You query AD using LDAP. In a AD that contains 10,000+ users you might have the admin users (say 50) in their own organizational unit (OU). By limiting your LDAP query to a specific OU you will in turn speed up the time it takes to complete your AD query. This is important in an AD with 10,000+ users.

Box293 wrote:* I DO NOT want usernames to be case sensitive. I don't care if the user logs in as UserLast1 or userlast1, only the password should be case sensitive.

To put it another way, in AD usernames are not case sensative when a user performs an authentication request. If you are going to be athenticating user accounts stored in AD AND you are going to be case sensative then you are going to be running into problems. And on top of that you are trying to force a standard onto a user that they are not used to and isn't required for any reason at all. All you will be doing here is frustrating the user! If they don't remember to type their username a particular way and are denied access then they will need to re-enter their credentials a second time just to log on. At this point the user has probably been put in a negative state of mind and all they'll be thinking is "stupid program blah blah blah,". That negative experience is the thing that they will more than likely tell other users when talking about Nagios, that is just human nature. About 2 out of 10 people will tell someone else how good something is, 9 out of 10 people will tell someone else how bad something is.

I hope all of this helps you understand why I put forward nine reasons for what I would like with LDAP / AD authentication. Please ask me for more details if required as I am more than willing to help.

Box293 wrote:

Box293 wrote:* Support for groups. So instead of adding a new user to AD and then going to XI and adding the user with specific permissions I would like to be able to add a user to AD, add that user to an AD group. That AD group has already been configured in XI with all the correct permissions. The user at this point can immediately log in.

I have seen this type of functionality in our SonicWALL Pro4100 firewall. We use the SonicWALL Global VPN Client (GVC) to allow users to remotely connect to our network. In the Active Directory userA is a member of RemoteGroupA and userB is a member of RemoteGroupB. On the SonicWALL device two groups exist, RemoteGroupA and RemoteGroupB. Each of these groups determine what network resources they have access to. When the user connects with the GVC it checks the Active Directory to see if the user is a member of RemoteGroupA or RemoteGroupB. If they are, then they are granted access. NOTE: On the SonicWALL Pro4100 there are no user accounts created, once the SonicWALL was configured for AD / LDAP integration, no additional configuration is required, all you need to do is add a user to either RemoteGroupA or RemoteGroupB in AD and they will be granted access the next time they logon using the GVC. Remove the user from the group and they no longer have the ability to logon with the GVC.

So this is the real benefit of having support for groups. I could have seperate groups in AD that reflect different security roles I have defined in Nagios XI. By simply adding or removing a user from a group I can instantly grant or revoke the type of access the user has to Nagios XI.

Yes, I see. As mentioned previously if each user's NagiosXI settings, email address being most important, can't be fetched from AD then you would end up needing to create this extra information statically in NagiosXI.

Assuming the goal was to remove the one object for one user constraint currently in place, other whole features of our product would be unavailable to you. Notification periods that might normally be set per Contact for example. Thus making this impractical for some of our users. We could auto-provision Contacts after they login, but they would never be removed and we would have to avoid copying the password or the email address.