- What Adaxes permissions does a user need to be able to view the log of a scheduled task?
The thing is that you cannot grant certain permissions to certain types of Adaxes Configuration objects (like only Scheduled Tasks, or only Business Rules etc), you can only grant permissions to all Adaxes Configuration Objects. This is because if your users are not granted the permission to view all configuration objects, they will not be able to browse inside the Configuration container and its subcontainers. So, what you can do is to assign the built in Domain User Security Role to the users you need and include Configuration Objects into the Activity scope of the Task. However, keep in mind, that in this case your users will be able to see all Adaxes configuration objects.
- I want to run a scheduled task for users who have enrolled for Self-Service (a monthly reminder to reset their answers if they've now forgotten them) and another for those who haven't (to enroll), is there an attrinute that I can use to trigger this different behaviour (i.e. adm-PasswordSelfServiceEnrollmentInfo).
There is no built in condition to check whether a user is enrolled with Password Self Service, but you may do this with an If PowerShell script returns True condition. The thing is that any user object in Adaxes exposes the IAdmPasswordSelfServiceOps interface that can be used to check whether an account is enrolled for Password Self-Service. For this purpose, you need to check the value of the IsEnrolled property of the interface. To check whether a user is enrolled in a Scheduled Task:
-
Create a new Scheduled Task.
-
On the 3rd step of the Create Scheduled Task wizard, select the User object type.
-
On the 4th step, add an action that the task should perform when the user is enrolled for Password Self Service, for example, Send e-mail notification and click OK.
-
Press the Add Condition button.
-
Select the If PowerShell script returns True condition.
-
Specify the following PowerShell script in the Script field:
$Context.ConditionIsMet = $Context.TargetObject.IsEnrolled
-
Enter a short description for the script and click OK.
-
Click the Add action to a new set link.
-
Add an action that the task should perform when the user is not enrolled for Password Self Service and press the Add Condition button.
-
Select the If PowerShell script returns True condition.
-
Specify the following PowerShell script in the Script field:
$Context.ConditionIsMet = !($Context.TargetObject.IsEnrolled)
-
Enter a short description for the script and click OK.
- Is there any way to control the objects returned in searches other than by controlling a users ability to see them?
Currently, there is no possibility to hide objects from users only in search result lists. If you hide AD objects from users, they will not be available to users anywhere in Adaxes environment.
- What permissions are required for a user to see their Password Time Remaining?
The users need to be granted the permission to read the Domain-DNS object that represents the domain they are located in. Additionally, if you use fine-grained password policies in the domain, the users need to be granted the permissions to read the container that stores fine-grained password policies for the domain. The Distinguished Name (DN) of the container is CN=Password Settings Container,CN=System,DC=domain,DC=com, where DC=domain,DC=com is the DN of your domain.
When changing an account password via Adaxes it's definately working, as immediately locking and unlocking the PC requires the new password, however, we can still login to the Adaxes web UI using the old password.
The thing is when you change a password for a user, Active Directory still allows access with the old password for a certain amount of time using the LDAP protocol. And since Adaxes uses the LDAP protocol to access Active Directory, you can still login with the old password for that amount of time.
- Similar to 3) A 'self-service' user can see the DL's they are in, but not those that others are. Funnily enough this may be what we want, but I want to ensure that we can allow them to view some groups (based on the OU they are located in etc). When I view 'a.n.other' users account, the 'DL membership' view is empty - I browse to a group I know they are in, and I can see it, and see the user is a member - so I must be missing read-access to an esoteric attributute of the user object (I have granted Read group membership etc).
It looks like the user, with the credentials of which you are trying to view group members, does not have successful permissions to read the MemberOfGuid and DirectMemberOfGuid properties of user objects. In this case, the Member Of section of those user objects, which the user cannot view membership for, will not function normally. This is a bug that will be fixed in our next version.
As a workaround for now, you can grant your users the permissions to read these properties. For this purpose you need to create a new Security Role that grants the necessary permissions or modify an existing Security Role and add the necessary permissions to it. To do this:
-
Launch Adaxes Administration Console.
-
Expand the service node that represents your service.
-
Right-click any object under the expanded service node, point to New, and then click Security Role.
or
Expand Configuration / Security Roles and select the Security Role you want to modify.
-
On the 2nd step of the Create Security Role wizard, click Add.
or
Click the Add button above the list of permissions.
-
In the Add Permissions dialog that appears, select the User object type.
-
Select the Show all properties option.
-
Select the Read 'MemberOfGuid' Property and Read 'DirectMemberOfGuid' Property permissions in the Property-specific permissions section.
-
Click OK.
-
Finish creation of the Security Role.
or
Save the modified Security Role.