Vanilla 1 is no longer supported or maintained. If you need a copy, you can get it here.
HackerOne users: Testing against this community violates our program's Terms of Service and will result in your bounty being denied.
Options

Active Directory Integration

2»

Comments

  • Options
    I'd also love to see this as an extension or internal feature. My boss wants to intergrate all our external apps (Vanilla (2 separate installations), Wiki, MantisBT) with LDAP access so we have a single sign-on, per say. If Vanilla was able to connect to LDAP via an extension or internal function, it'd be awesome!
  • Options
    edited July 2007
    I want to download Jonathans LdapAuthenticator class, but the link doesn't seem to work. Can anybody provide this extension to me. Thanks!
  • Options
    edited July 2007
    Nevermind my previous post, found it here.
  • Options
    i'm trying to use the code above to get working with AD, i've found that at least one hangup is here: ldap_bind($connection, $rdn, $password) replacing $rdn with accountame@domain.com binds but then obviously doesn't work when reading attributes.
  • Options
    edited October 2007
    .
  • Options
    edited October 2007
    got it. email field in AD needs to be filled. How can I add multiple OU into the authenticator ? LDAP_RDN seems to want only one OU... I want the whole domain to be queried. I have something like 25 OU. Is there a way to use the sAMAccountName instead of the CN for the user name ? this might help but I don't know how to implement it into PHP. http://www.microsoft.com/technet/scriptcenter/resources/qanda/apr05/hey0412.mspx have a look at this also, it does a search on the ldap server for the samaccountname. tried to intergrate it but it doesn't work. http://www.havocstudios.co.uk/blog.php?title=ldap_authentication_using_php_(the_basics) Thank you so much.
  • Options
    edited October 2007
    .
  • Options
    edited October 2007
    .
  • Options
    Finally ! Here is the code that will authenticate user over an ENTIRE Active Directory Domain. It's using the sAMAccountName to search the ldap directory. Once it finds it, it put the DN into the LDAP_RDN variable. Since i have users that don't have an email address define in AD, I'm using userPrincipalName for the LDAP_ATTR_EMAIL variable. The code is dirty, it open two ldap connections... Please Keep in mind that i am not a programmer. Someone might clean it one day. Here is it. http://pastebin.com/f35afb1b
  • Options
    Sounds good! You should make an extension package and put it on the addons site!
  • Options
    one problem still. user having accent in their name can't log in. (é è ë ...) I tried utf8_encode and it still doesn't bind. I have to remove the accent from their name to bind. Any idea?
  • Options
    I'm going to resurrect this thread. Johnathon's LDAP Authenticator works great (http://wallphone.com/People.Class.LdapAuthenticator.zip). I'm going to see what I can do to make an actual extension out of it. Some things I was thinking of, for instance, are the ability to have a super-admin ID that does not have to be in the LDAP directory (so the super-admin can sign in even if LDAP breaks), and the ability to extract addition information from LDAP to populate the profiles. That is, of course, if I can figure out how to write an extension in the first place... Meanwhile, I'm already faced with an issue and I'm not sure this is the best place to post it. I'm pulling additional information out of our LDAP tree such as work location. It's easy enough to add a few lines to Johnathon's code above, but eventually I need to plug it into the profile. So I add the additional elements to the users "attributes" field as such,         $user->Attributes[] = array('Label' => 'Location', 'Value' => $user_location); But apparently we're not allowed to add attributes at sign in because I also have to modify People.Class.UserManager's CreateUser() function thusly, //     $s->AddFieldNameValue('Attributes', '');         $s->AddFieldNameValue('Attributes', $SafeUser->Attributes); I'm sure this is because Mark O'Sullivan did not foresee creating attributes at sign in. But with authentication occurring against a directory service, many additional attributes can get passed. So ideally I'd like to see this as a permanent change to People.Class.UserManager. But that's not the way it is right now. My big question; does anyone know how I can update the attributes field during first sign-on without having to modify People.Class.UserManager?
This discussion has been closed.