1

I'm pretty new to Craft, and we have been trying to implement a front end LDAP authentication to our website at my organization. I found the ADLDAP plugin and have been testing it with the website.

Here's the link to the AdldapController.php file that seems to have most of the logic for the plugin: https://github.com/thepitagroup/adldap_craftcms/blob/master/adldap/controllers/AdldapController.php

I was looking at the code in the AdldapController.php file and was wondering if the check for a matching username in Craft is necessary?

To clarify, my organization only desires to authenticate by Active directory. It looks like this script is also checking to see if the user exists in the local craft user table (line 62). (Am I correct in understanding that this script will put the username/password combo from active directory verbatim into the MySQL table for future use, or is a new craft-only password generated?) Can this block of code be omitted as an 'option?' Pros/cons?

Thanks for any leads or input.

1 Answer 1

1

In order to navigate as a user in craft the user needs a record in the users table. So what the plugin does is the following

  1. Starting an authentication by active directory
  2. If the login credentials are correct it searches if a craft user exists
  3. If there is no craft user connected to the active directory user it creates a new user with the same name/password like he/she has in active directory
  4. If there is a craft user instead of checking the password with the craft user - in case you changed it in active directory - it just overwrites the current craft user password every single time a user tries to login. The password will be crypted only for craft. There are no changes to your active directory

In summary: you don't need to be afraid, there are no changes in active directory but every time a user tries to login his password will be stored into the db again and again.

The Code is not optional, you have to store the active directory user as a craft user in order to change their permissions otherwise they won't be able to login to the backend or make any changes unless you implement your own logic/controllers to manage the content.

Edit
just some more thoughts: If your users won't be able to login to the backend and should be able to make changes only via frontend requests, there is no need to store them as craft users, so you could eventually(!) - depends on the rest of the plugin - remove that block but you won't be able to use crafts build-in functions like detecting which user made certain changes.

You would have to create a custom logic to give them permissions (if needed) and you would have to log user activities by yourself (if needed). So if you want to see who did something you have to include a custom username field for every entry.

Furthermore you can't use the craft->userSession service to get current user information and you have to implement logic that the user is actually logged in by yourself (store some values in the $_SESSION) You can't use crafts currentUser global in twig as well -> you need a custom twig extension or a custom function.

All controller actions must be allowed for everyone so they can't access all the craft default controllers since most of them don't allow anonymous requests.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.