KACE Product Support

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.

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.

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.

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

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.

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.

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.

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.