Hello, I am trying to use Wildfire+LDAP to authenticate users. AlternateBaseDN tag seems not to be working for me. Users are spread across two DN.
1.ou=prg-dc,l=ea,l=global,o=company.com , that’'s where my colleagues are
2.ou=eadc,l=ea,l=global,o=company.com, my DN
When I use only baseDN tag and switch these two, either me or my colleague can login without any issues.
With following setup, I cannot login (I am member of alternateBaseDN).
wildfire, I am forwarded to administrator login page again
Any hints?
I’‘ve been using Wildfire since the 1.4 days (it was called Messenger back then), and I’‘m still not clear what the alternateBaseDN does and doesn’‘t do…so I’'m no help there.
I’‘ll ask the obvious question: is there any reason why you can’'t make l=ea,l=global,o=company.com[/b] your baseDN?
Hi, I’'ve tried that and it works. But Users/Groups section in Admin console is then unavailable, likely due to amount of users which is likely more than fity thousands. Therefore I would like to resolve this. It seems it is always trying to use alternateDN, just not in the last attempt.
It seems to me that the alternateBaseDN was improperly implemented. I attempted to fix it a bit ago but failed to do so completely because I had no way to test my work. I will try and fix it for real this time.
Hi, thanks for reply, can we have this filled as a bug?
Everything works when I use
l=ea,l=global,o=company.com , but there are over 50000 users in that subtree. I am only interested in ou=eadc and ou=prg-dc subtrees. I’'ve tried to use
to filter only these two, but I cannot login with such a setup. Am I missing something?
I’‘m using a searchFilter, as we have all our Wildfire users in one Active Directory group. If you want to use one to select just those users in one of the two DNs you gave, you’'ll need to have your base DN be their greatest common factor (l=ea,l=global,o=company.com, I presume), then have the searchFilter be something like:
/code
(I’‘m not certain about your uid attribute; mine’‘s actually sAMAccountName, as it’‘s AD’'s schema)
If something more or less like that doesn’‘t work, then I’‘m not sure, as it’'s working fine in our setup now.
Good luck!
Timothy Collett
I’'m not sure of the process, but yes it should be filed as a bug.
As for your situation I think you would be much better served by using a search filter like the one recommended by Robert Smol, than using altenateBaseDN.
Cheers