LDAP log in from AD
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
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
Answers (12)
Please log in to answer
Posted by:
airwolf
12 years ago
Posted by:
jbowes
12 years ago
Posted by:
airwolf
12 years ago
Posted by:
jbowes
12 years ago
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...
[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...
Posted by:
airwolf
12 years ago
Posted by:
jbowes
12 years ago
Posted by:
GillySpy
12 years ago
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
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)))
Posted by:
airwolf
12 years ago
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).
Also, the LDAP Login Name needs to be in the LDAP format (e.g. CN=kboxldap,OU=Users,DC=domain,DC=com).
Posted by:
jbowes
12 years ago
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.
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.
Posted by:
jbowes
12 years ago
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
It's a bit puzzling.
--james
Posted by:
airwolf
12 years ago
Posted by:
jbowes
12 years ago
![](/build/static/general/appdeploy_logo.png)
so that the conversation will remain readable.