However, if they then view another user object (either via the search function - which we can disable if needed - or clicking on their 'Manager' etc - which we can't) they can also see this information for other accounts (basically most of the account info data, though not the log-on name).
Even if I specifically block the ability to, for example 'Read Logon Hours', I can still see this attribute.
The thing is that when the access control system denies access to a certain property of an AD object, it returns information that the object does not have such a property, that is, the property is treated as unspecified. This works well for most of the properties, but not for all of them. For example, if the Logon Hours property is not specified for a user, this means that logon is always allowed at any time. That is, allowed to logon at any time is sort of the 'default' value that is assumed when there is no information about allowed logon hours. Approximately the same happens with password expiration, and the 'default' value is No Expiry.
So, if a user has permissions granted by the Security Roles that you've described, he/she will still see certain 'default' values for some properties, but that doesn't mean that the values that he sees are actual and valid.
I cannot view the domain password policy for the managed domain via the console (logged in as the service account), even though users changing passwords via the Adaxes web UI can view the effective domain policy.
The error I get is "You are not allowed to read 'objectClass' or 'objectGuid' properties". Note: I also get the same error when logging in via the console users a user account that can view the policy via the web UI.
The most probable reason for such behavior is that the account of the default service administrator does not have sufficient 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. You need to grant the default service administrator the appropriate permissions.
It would be very useful to have a bit more information on assigning privileges for the service account within AD
Usually, the permission to read everything is enough to avoid similar issues.
and hopefully 2013.1 is also coming out tomo :)
Nope. The new release is delayed for two weeks.