Environment
Self Service Password Reset
SSPR 3.3
SSPR 3.2
SSPR 3.3
SSPR 3.2
Situation
SSPR helpdesk users have too many rights
SSPR help desk users can access users they shouldn't
Helpdesk users with limited access are able to change passwords for users they should not have rights to change.
SSPR help desk users can access users they shouldn't
Helpdesk users with limited access are able to change passwords for users they should not have rights to change.
Resolution
Edit the list of Heldesk profiles to move the limited profile at the top of the list.
Result:
NOTE: When applying profiles, SSPR applies the first matching profile in the list. It stops looking after the first match is found. This is true in all SSPR modules.
Result:
NOTE: When applying profiles, SSPR applies the first matching profile in the list. It stops looking after the first match is found. This is true in all SSPR modules.
Additional Information
Troubleshooting Notes:
Customer wanted to have two types of help desk users.
An SSPR troubleshooting bundle was captured that included the following:
- Login as user “testit,â€
- Launch the helpdesk module,
- Search for user “Bert"
- User "Bert†shows in the list of users found with the search. Bert is a user that the “systemManagers†group should not have rights to access.
- Select user “Bert“ and verify that “testit†could access his information profile.
SSPRdebug.log shows that testit matches the Default Help desk profile.
Line 9201 - 2015-10-09T15:36:03Z, DEBUG, ldap.LdapPermissionTester, {1ie} user UserIdentity{"userDN":"CN=testit testit,OU=Staff,dc=XYZ,dc=whatever","ldapProfile":"default"} is a match for '(objectClass=*)'
And is assigned the default helpdesk profile.
Line 9200 - 2015-10-09T15:36:03Z, DEBUG, ldap.UserStatusReader, {1ie} assigned Helpdesk profileID "default" to CN=testit testit,OU=Staff,dc=XYZ,dc=whatever
(note that most recent events are at the top of the log)
SSPR goes down the list of profiles and stops after a match is found. Customer changed the list of Heldesk profiles to put “SystemManagers†above “default.†This resolved the problem.
Customer wanted to have two types of help desk users.
1. A group of admins who could change passwords for anyone, anywhere in the directory. This profile had not been fully configured yet, but was to be the default help desk profile.
2. A group of Helpdesk users who could only make changes for a subset of users in a certain container. This profile was given the name of “SystemManagers.â€User “testit†was configured to be part of the system managers group of helpdesk users with limited rights. The problem was that testit was able to see all of the users in the directory.
An SSPR troubleshooting bundle was captured that included the following:
- Login as user “testit,â€
- Launch the helpdesk module,
- Search for user “Bert"
- User "Bert†shows in the list of users found with the search. Bert is a user that the “systemManagers†group should not have rights to access.
- Select user “Bert“ and verify that “testit†could access his information profile.
SSPRdebug.log shows that testit matches the Default Help desk profile.
Line 9201 - 2015-10-09T15:36:03Z, DEBUG, ldap.LdapPermissionTester, {1ie} user UserIdentity{"userDN":"CN=testit testit,OU=Staff,dc=XYZ,dc=whatever","ldapProfile":"default"} is a match for '(objectClass=*)'
And is assigned the default helpdesk profile.
Line 9200 - 2015-10-09T15:36:03Z, DEBUG, ldap.UserStatusReader, {1ie} assigned Helpdesk profileID "default" to CN=testit testit,OU=Staff,dc=XYZ,dc=whatever
(note that most recent events are at the top of the log)
SSPR goes down the list of profiles and stops after a match is found. Customer changed the list of Heldesk profiles to put “SystemManagers†above “default.†This resolved the problem.