Alan DeKok wrote:
On Mar 30, 2015, at 9:39 AM, Adam Schappell <aschappell@clearedgeit.com> wrote:
Thanks for the suggestion, since I havent read it already 10 times. Thanks for a little insight tho, appreciate it.
Really? You’ve read it 10 times, and still don’t know what’s going on?
If you (a) speak English, and (b) understand your LDAP schema, it should be pretty clear.
[ldap] performing search in dc=corp,dc=clearedgeit,dc=com, with filter (uid=radius) [ldap] rebind to URL ldap:// ForestDnsZones.corp.clearedgeit.com/DC=ForestDnsZones,DC=corp,DC=clearedgeit,DC=com [ldap] rebind to URL ldap://DomainDnsZones.corp.clearedgeit.com/DC=DomainDnsZones,DC=corp,DC=clearedgeit,DC=com [ldap] rebind to URL ldap:// corp.clearedgeit.com/CN=Configuration,DC=corp,DC=clearedgeit,DC=com [ldap] object not found
Do the words “not found” mean anything?
The server prints out the LDAP searches it’s doing. It prints them out for a REASON. So you can READ THEM, and manually verify them against the LDAP tree.
Hmm, this looks like the referrals in MS AD are automagically chased. LDAPv3 referrals are a broken concept anyway and I doubt that FreeRADIUS in particular will find any meaningful entries in the referred AD containers above. => I'd switch off referral chasing to avoid this noise in the logs. This does *not* mean that checking with LDAP client tools is not useful in general. Ciao, Michael.