I'm using an ITIM 5.1 instance where I want users to be able to see and modify their own Shared Secret. The ITIM administrator is able to see and modify the Shared Secret for all users, but the users themselves cannot see or modify their own Shared Secret. I have viewed all the ACI that by name would seem to affect the user's ability to see/modify their Shared Secret, but none seem to deny read/write to the attribute. I have also viewed all ACIs in the root OU and I've looked at all the ACIs in the People OU that have a Protection Category of Person and I can't seem to find an ACI that is restricting access.
I use 'Deny' very sparingly, but even so I've checked for ACIs that have been named with Deny (convention is to describe what's being allowed/denied in the ACI name). Initially I started going through all the ACIs, but there are hundreds, so that seemed pointless and error prone.
Is there any way to identify all ACIs that affect the Shared Secret attribute that have some permission other than 'None' (Grant/Deny)?
Is there something in ITIM that could be restricting a user's ability to see the Shared Secret attribute other than an ACI?
Michael K. Craghead