Hi folks.

I have been working off and on with the K1000 for about 1 month. So far I have been able to import users via LDAP and as far as can tell, all tests have been working. So now I am establishing a pilot group for testing the ticket system and training users but this is where the problem is.

Users cannot log into the web interface.

I have double-checked all settings and they appear correct and appear to be working. My LDAP search context starts at the top of the domain as we have multiple sites in AD. After having tested that for looking up all users from any of the sites, I thought that keeping the LDAP context at the top level was probably the best thing to do and certainly it was the only thing that worked in terms of importing users into LDAP.

Not sure if that thinking is correct or not. Also, I have read and re-read the document and from what I understand you can schedule an LDAP import of users; I know some KACE admins are doing that but until I get this log in working, I'd rather wait.

My context looks like this:

dc=company,dc=local

The LDAP user is put in this way:

domain\kaceuser

Now as I stated, I can look up users without issue but they cannot log in.

Any suggestions with this issue would be greatly appreciated.

--james
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

0
My guess is your LDAP filter is the problem. LDAP importing just imports the user info - it isn't used for authentication. LDAP Authentication is separately defined.
Answered 09/21/2011 by: airwolf
Tenth Degree Black Belt

Please log in to comment
0
I think so as well but others from my IT department can log in as well. So is it possible to use multiple search filters?

--james
Answered 09/21/2011 by: jbowes
Orange Senior Belt

Please log in to comment
0
I have two LDAP authenticators - one is for members of a specific group (to gain admin access) and the other is for regular users to access the user portal.
Answered 09/21/2011 by: airwolf
Tenth Degree Black Belt

Please log in to comment
0
For me the troubling thing is the potential complexity. Here is an example of the domain:

[center]domain[/center]
[center]|[/center]
[center]Site A[/center]
[center]| |[/center]
[center]OU:PC Users OU:TS Users[/center]

And it goes on for quite a few sites... How would I deal with the look ups because it seems to me they would then be nested...
Answered 09/21/2011 by: jbowes
Orange Senior Belt

Please log in to comment
0
I have this setup as the filter - it allows all domain user accounts to login with the user role.
(&(samaccountname=KBOX_USER)(ObjectCategory=CN=Person,CN=Schema,CN=Configuration,DC=domain,DC=com))
Answered 09/21/2011 by: airwolf
Tenth Degree Black Belt

Please log in to comment
0
Okay that seems to make sense... I id try it that and it doesn't work for me. Just so I understand, does that belong in the Search Filter section?

Thanks for your suggestions BTW.

--james
Answered 09/21/2011 by: jbowes
Orange Senior Belt

Please log in to comment
0
To be clear -- there is an import of users and then there is authentication so make sure that you are setting up both . The scheduled import is linked from the authentication page.

settings->user authentication

To narrow in on a subgroup keep do something like the "beef it up" section of this faq: example search filter
(&((msExchUserAccountControl=0))(&(memberOf=CN=Western,OU=Sales,DC=Copr,DC=Kace,DC=com)(samaccountname=KBOX_USER)))
Answered 09/21/2011 by: GillySpy
Seventh Degree Black Belt

Please log in to comment
0
Yes, that's the search filter. And the Base DN needs to be "DC=domain,DC=com". And in both instances, you'll need to replace the word "domain" with your actual domain. I put the word "domain" in there as a placeholder.

Also, the LDAP Login Name needs to be in the LDAP format (e.g. CN=kboxldap,OU=Users,DC=domain,DC=com).
Answered 09/21/2011 by: airwolf
Tenth Degree Black Belt

Please log in to comment
0
Okay I have had to use to the DN of the kace ldap user in order to apply a search filter. Here is what I now have in place:

Search Base DN: dc=domain,dc=local
Search Filter: (& (samaccountname=KBOX_USER)(ObjectCategory=CN=Person,CN=Schema,CN=Configuration,DC=domain,DC=local))

LDAP Login: cn=kace ldap,cn=Users,dc=domain,dc=local

This successfully binds and authenticates. However, while I have admin membership in AD, a regular I am using for testing cannot log in.
Answered 09/21/2011 by: jbowes
Orange Senior Belt

Please log in to comment
0
Hmm since re-reading one of the responses, I am now confused about the import (should equate to reading LDAP) VS the authentication. Would the authentication require a domain admin or is the KACE Ldap user sufficient. I ask because when using the KACE Ldap user, I can log in with no problem while a regular user cannot.

It's a bit puzzling.

--james
Answered 09/21/2011 by: jbowes
Orange Senior Belt

Please log in to comment
0
The account you use for the LDAP lookup needs read-only rights to AD.
Answered 09/21/2011 by: airwolf
Tenth Degree Black Belt

Please log in to comment
0
Well another day, another dollar.

I am still unable to log in with a test user. Incorrect username or password is the only message. I do believe it is an LDAP configuration issue but I am stymied.

--james
Answered 09/22/2011 by: jbowes
Orange Senior Belt

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