KACE Product Support

The way that KBOX LDAP auth works, it only require read and search permissions on your LDAP source. Authentication happens with two binds, or LDAP logins: the first bind is as the "LDAP Login" you configure for the LDAP server assigned to the user role. That LDAP user only needs to be able to read and search in the search base you configure there.

When a user logs in, we do a first bind as that LDAP login, and look for the user who typed their name in the KBOX login page. We find the user using an LDAP search you configure in that LDAP search area. A typical search might be

(&(samaccountname=KBOX_USER)(memberof=CN=KBOX Admins,OU=Users,DC=kacelabs,DC=com))

Before we search LDAP, we substitute in the login the user typed in at the KBOX login page ui. If I typed in "jk", the search would go as

(&(samaccountname=jk)(memberof=CN=KBOX Admins,OU=Users,DC=kacelabs,DC=com))

This LDAP search says, "Look for a user in the Search Base [not shown here] whose short name (samaccountname) is 'jk' and who's a member of the security group 'KBOX Admins', defined in possibly another container which could be outside our Search Base [OU=Users,DC=kacelabs,DC=com]."

That search will return a distinguished name to use. Let's say our search base is "OU=Cincinnati,OU=Ohio,DC=kacelabs,DC=com". That query might return something like

CN=Karabaic\, John,CN=Users,OU=Cincinnati,OU=Ohio,DC=kacelabs,DC=com

for my distinguished name (DN). Then we bind a secondary time, using my DN and the password I typed in. If the bind succeeds, I'm logged into the KBOX using the role defined for that LDAP server.

By the way, you don't need to specify a DN for the LDAP login if you're going against AD. user@domain or domain\user should work.

The active directory account only requires the rights necessary to query your structure. The level of the user is really dependent upon your environment, but most people should have no problems if the user account created for KBOX LDAP queries is just a standard user account (this is how ours is setup). When you configure the LDAP authentication, make sure you put the full path to the user account you create (i.e. you can't just put DOMAIN\Username for the LDAP user, you would need CN=User's Name,OU=Users,CN=domain,CN=com)

By the way, you don't need to specify a DN for the LDAP login if you're going against AD. user@domain or domain\user should work.
I'm running AD, and I had to use the DN. User@Domain and DOMAIN\User do not work. We're running a 2003 AD infrastructure. I'm not complaining, just throwing it out there that you may be required to use the DN even if you are running AD.

In answer to the original question, you do not need to make a KBOX_USER account on your domain.  In the context of the filter, it is a variable that we pass along to your AD.  So, for example, if Bob Smith is trying to log into your K1000, the KBOX_USER is really Bob Smith.  So we pass Bob along to your AD to see if his credentials meet all of the conditions of your filter.

Hi Brandon,
I was trying to configure K1000 Virtual appliance for LDAP Authentication to login to the web interface with AD users.
username and password you provided do not work. Could you update the information?
Thanks.

Here is a sample screen shot of a functioning LDAP K1000 console login configuration. Hope it helps!