Minimum service access rights

Question

Hi,

Getting ready for the final testing...(hopefully on the 21st!)

Can I just confirm the minimal access rights required for the service account as to date we have tested using a domain admin account (that was also a member of the BUILT-IN\Administrators group)?

As per your online guidance in "Grant Permissions to Publish Adaxes Service", we can create a 'normal' service (user) account and grant it "Create/Delete Child Objects" rights to the domain root object? This should give the service account all the access that Adaxes needs to create a SCP, access AD via LDAP and create/delete/modify objects?

We have also tested explicitly blocking write access to some OU's (to prevent changes to high value objects e.g. domain controllers) when using a privileged account and this worked as expected (we could still read data using Adaxes but could not make changes). Can you confirm if this is a supported setup or could we have problems 'down the line'?

Many Thanks

Answer 1

As per your online guidance in "Grant Permissions to Publish Adaxes Service", we can create a 'normal' service (user) account and grant it "Create/Delete Child Objects" rights to the domain root object?

No. To be able to publish Adaxes service, the service account should be given the right to Create/Delete Child Objects to the computer, on which Adaxes is installed (and not to the domain root object) as mentioned in Grant Permissions to Publish Adaxes Service. This will give the account the necessary rights to create a Service Connection Point (SCP) under the computer object. The created SCP will be used by to publish information on Adaxes service in Active Directory and enable automated service discovery.

As to rights to create/delete/modify objects, you need to explicitly grant the required rights with the help of native AD security. For example, if you want to allow Adaxes create and delete objects in an OU, you need to grant the service account the Allow create/delete all child objects right for that OU.

Also, don't forget that Adaxes allows registering domains only with the credentials of an account that is a member of the BUILTIN\Administrators group. If you want to allow registering domains with credentials of an account that is not a member of this group, you need to configure Adaxes to skip permissions check when registering domains. For instructions on how to do this, see Skip Permission Check When Registering Domains

We have also tested explicitly blocking write access to some OU's (to prevent changes to high value objects e.g. domain controllers) when using a privileged account and this worked as expected (we could still read data using Adaxes but could not make changes). Can you confirm if this is a supported setup or could we have problems 'down the line'?

Yes, actually this is one of the recommended practices.

Comments

Many thanks - that's why I checked!

It was this bit that confused me - I thought we were talking about the context of the "domain" object as opposed to the server object Adaxes was installed on:-

4. Right-click the computer object, on which you want to install Softerra Adaxes, and then click Properties.

Something like this may be clearer (with a FYI to repeat for all subsequent installs on DR servers etc):-

4. Right-click the server object on which you are installing Softerra Adaxes, and then click Properties.

As this was the only part of the install instructions that referenced "permissioning" the service account I had assumed that it had to be refering to granting permissions to AD! Maybe a point 8. adding that you will need to specify the native access rights seperately may help?

Thanks also for the pointer about suppressing the BUILTIN\Administrators verification.

Rgds

---

We are not currently planning to update our Installation Notes, but thank you for your active participation. We really appreciate it.

---

Thanks.

You may not want to answer this question in the forum, but....

I'm 'refreshing' our test server to go through a "install, config, use" cycle (to demo how quickly we can get Adaxes up and running, and the low management overhead etc) and have hit an issue where, even though we have a completely new install (no Adaxes config restores etc) after about 10 minutes of use we get the license expiry error message.

Is there anything in the registry etc that I need to remove to get a new test window? As noted I have fully uninstalled the software, and re-installed without re-using any previous configurations (although as part of the process of re-configuring we are replicating the same UI customization etc) but I assume we must have left a trace somewhere?

Plan B is to run up a new server image, but that sometimes takes longer than expected!

Rgds

---

We suggest that you drop a message to our Sales Department (sales[at]adaxes.com), and they'll extend your trial.

---

Hi - you're getting a PO v.soon - and hopefully 2013.1 is also coming out tomo :)

Sooo, we're documenting the final build target and have a issue based on the above thread.

We are now installing using a very restricted service account that is a 'standard' domain user that has been granted specific admin access to the OU's where we want it to be able to manage objects etc.

So far this works fine - but we have hit an issue where 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.

Are there any specific non-privileged, non-standard rights (i.e. read access to specific attributes types) I should grant the service account at the root of the managed domain that will fix this (and any other likely issues down the line)?

It would be very useful to have a bit more information on assigning privileges for the service account within AD - ideally a "these are the minimum rights to be able to read/view all objects/attributes without throwing errors" idiots guide (I'm not precious!). Once we have those we can extend to cover the 'managed' OU's on a case by case basis.

I guess a lot of people just add it as a domain admin account - but that's not something that we believe should be necessary, and certainly not until it has been proven robust in-situ.

Rgds

---

...and now I have a new question :roll:

On a user-self service page we are allowing users to see when their passwords expire - a very useful bit of info.

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).

I have tried playing around with Adaxes RBAC roles and I just cannot seem to find a way of blocking this.

My currently active roles are the built-in role for Self-Service (self object) , and a Domain User role that grants 'List Object', 'Read Object Class' and 'Read Object GUID' to other users objects - which allows me to 'open' other users, and see their display name and nothing else - other than the account info!

Even if I specifically block the ability to, for example 'Read Logon Hours', I can still see this attribute.

Rgds

---

Hello,

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.

---

Many thanks - I have permissioned access to the password policy container as directed and we can now view the domain password policy via the console.

Shame about 2013.1 - have been looking forward to getting my hands on it!

Rgds