So we just got hit with a concerning issue regarding LDAP Authentication. An administrator of another Org had switched his Org to use LDAP authentication, but never configured the servers. So anytime anyone else on the entire box tried to log in with their local accounts, the KBOX tried to authenticate against the default (non-existent) LDAP servers configured on that one Org. It took about 5 minutes for all the timeouts.

Getting to the kbox was possible through the 'admin' account (apparently the Kbox knows to always authenticate this account locally).

The concerns are a few:

  • If each org has its own LDAP server that they manage, authentication will "break" on the whole box if one of those LDAP servers goes down.
  • Even if specifying the Organization explicitly while logging in, the KBOX still seems to try to authenticate the user to other Organizations' LDAP servers. If we have 20 orgs and 20 different LDAP servers, this could turn into a 5 minute login process every time.
  • It seems that if LDAP authentication fails, it drops to local authentication. Shouldn't local auth be first, especially when explicitly specifying a domain that uses local authentication only?
  • Even users that exist solely in the System org (that does not have any LDAP auth options) are forced to wait for the timeouts before being given access.


I must be missing something right? Because this seems like really strange behavior to me (and a liability).

The reason we chose the KBOX as our desktop management solution was the whole Organization structure where we could allow autonomous departments to feel like they have their own KBOX while we manage the System org. But this authentication behavior seems to break from that model. The solution can't be that we have to give everyone their own KBOX, could it? Then we'll be storing redundant patches...
0 Comments   [ + ] Show Comments

Comments

Please log in to comment

Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.

Answers

1
It seems like you've stumbled upon a single point of failure issue. I don't see anything that's "broken" based on your explanation, but it does seem like something DellKACE would want to change.

I'd suggest submitting an enhancement request to support to allow the user to specify their organization from the login screen (using a combobox, for example). Having the KBOX automatically hit each LDAP server for all organizations is inefficient even when they are all up, but can be devastating if one, some, or all of the LDAP servers are down.
Answered 03/03/2011 by: airwolf
Tenth Degree Black Belt

Please log in to comment
1
I don't consider it broken either because I know that I can either use the local 'admin' account to gain access or just wait the 5 minutes for all the timeouts. But if you consider that the login process should take less than 3 seconds, a 5 minute login process is broken by that standard.

There is a way to specify the KBOX to use a drop-down to select the Org. However, doing that does not stop the KBOX from trying to authenticate a user against every organization's LDAP server.

There are many instances with the KBOX where it seems like the developers covered every angle, and then there's an issue like this. I leave the possibility open that I'm missing some configuration option, which is why I created this post. But it certainly does seem like a single point of failure. I'll hold off submitting the enhancement request until I get some more feedback.
Answered 03/03/2011 by: stradric
Senior Yellow Belt

Please log in to comment
1
There is a way to specify the KBOX to use a drop-down to select the Org.

Then submit a support ticket, because it is a design flaw if the user can select an organization but the KBOX hits every org's authentication servers.
Answered 03/03/2011 by: airwolf
Tenth Degree Black Belt

Please log in to comment
1
Thanks for the feedback stradric. If you are having issues we definitely want to hear what those are and make them better. Keep in mind that these are community based forums and your questions are geared a lot towards problems you are having with the inner workings of the kbox so I recommend that you open a support ticket if you have maintenance. A ticket is ideal for sharing logs, getting someone to look at your box, etc.

That said, I'll certainly try to address some of your concerns here:
Each org has many things that will affect the entire box -- if someone writes a poorly performing query that affects everyone, a provisioning schedule against thousands of IPs, a patch job midday on everything. When working on shared devices this is always going to be true and you need internal rules to keep things smooth as possible and a global admin who can configure any ORG if need. Can you have a global admin that can go into any org to fix problems? Could local admins not have write permissions on every tab?

The kbox does not have an LDAP server running but an LDAP client that can authenticate to your servers. If the listed servers are unavailable the client on kbox will try for a while (don't have details atm) and then times out.

KBOX still seems to try to authenticate the user to other Organizations' LDAP servers
A quick test looks like it may be at least trying the connection from other ORGs. This is what a ticket would be great for

It seems that if LDAP authentication fails, it drops to local authentication. Shouldn't local auth be first, especially when explicitly specifying a domain that uses local authentication only?
The KBOX only support LDAP authentication or local authentication. You pick which one to use. The excepton is the local admin account always works so if you have LDAP issues you can go in with that account and remedy them or turn LDAP off. In that case admin (local ) is tried first. A quick test shows this is always quick.

Lastly, when an account was waiting to login due to an LDAP misconfiguration i was able to open another browser and log in quickly with admin user
Answered 03/03/2011 by: GillySpy
Seventh Degree Black Belt

Please log in to comment
1
Gerald, you make several valid points. However, I would be worried about a failure scenario where an LDAP server for one organization drops. This would obviously not be a configuration issue, and it would cause the long timeout for all users - not just the affected organization. That, in my opinion, is a design flaw - especially considering users have the choice of selecting their ORG on login. The KBOX should default to the login method for the chosen ORG; not randomly hit all ORGs until a match is found.
Answered 03/03/2011 by: airwolf
Tenth Degree Black Belt

Please log in to comment
1
For tomorrow, a ticket will figure out how to get any defects addressed.

In the meantime, logging in with admin account and fixing the authentication settings should allow users to proceed.
Answered 03/03/2011 by: GillySpy
Seventh Degree Black Belt

Please log in to comment
0
Thanks for the reply GillySpy.

So we do actually have a ticket open for this case. I was informed that this was a known bug with the KBOX. I'm still waiting to hear back if it was/will be fixed in 5.2.

The KBOX only support LDAP authentication or local authentication. You pick which one to use.

Right. This is the basis for my post. Essentially: Why is the KBOX trying to authenticate a user with a local account connecting to an Org with Local Auth over the LDAP auth in another Org?

It turns out there is an answer and it's not the blunder that I first suspected. It hinges around the 'Organization Fast Switching' feature that you can enable in the System org (and I believe is enabled by default). How else would the KBOX be able to populate the Organizational drop-down on the top right if it didn't authenticate each user against every Org in the system? So, while the loss of 'Organizational Fast Switching' is regrettable, it could be a potential solution/workaround in our environment.

I thank you for your replies. Hopefully this thread will help someone else in the future.
Answered 03/03/2011 by: stradric
Senior Yellow Belt

Please log in to comment
1
Makes perfect sense. So, if anyone reading is running into this and wants to alleviate the symptoms -- log into the SYSTEM org with the admin account (since it is local in all ORGS and SYSTEM) and turn 'Organization Fast Switching' off, then fix the settings.
Answered 03/03/2011 by: GillySpy
Seventh Degree Black Belt

Please log in to comment
Answer this question or Comment on this question for clarity