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
- Starting an authentication by active directory
- If the login credentials are correct it searches if a craft user exists
- 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
- 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.