We have had our own local patch which authenticates via Radius, but the time has come to move in the direction of LDAP and MS AD.
[ldap] enabled = yes server = dc10.ad.uit.no port = 636 encryption = ssl uid_attr = sAMAccountName basedn = ou=people,dc=uit,dc=no lookupmethod=direct suffix = @ad.uit.no
debug = yes
I get authentication to work with an existing account, but can not create a new account. The debug-log shows a strange ldap url during referral:
It begins ok: ldap_url_parse_ext(ldaps://dc10.ad.uit.no:636) ... connect success
But then: ldap_chase_v3referrals ldap_url_parse_ext(ldaps://uit.no/ou=people,dc=uit,dc=no)
Where does the domain uit.no in the URL come from? Is there a config setting I have overlooked?
This of course ends in Unable to chase referral "ldaps://uit.no/ou=people,dc=uit,dc=no" (-1: Can't contact LDAP server)
(If I use "lookupmethod=search" the webpage throws an error and no account is created. If I use "lookupmethod=direct" the account is created, but without Name, because that was not found in the search - since it was sent to the wrong server)
--Ingeborg
On Fri, 05 Jun 2020 10:54:55 +0200 Ingeborg Hellemo ingeborg.hellemo@uit.no wrote:
It begins ok: ldap_url_parse_ext(ldaps://dc10.ad.uit.no:636) ... connect success
But then: ldap_chase_v3referrals ldap_url_parse_ext(ldaps://uit.no/ou=people,dc=uit,dc=no)
Where does the domain uit.no in the URL come from? Is there a config setting I have overlooked?
Disclaimer: I'm no LDAP expert.
The server at dc10.ad.uit.no appears to respond to a request with a referral to another LDAP server at uit.no, and the client library appears to be attempting to chase that referral.
So, I'd say something is amiss with dc10.ad.uit.no itself, maybe? What was logged between connect success and the referral?