Hi Dave,
We had the same questions when we were adding our 5.2 to the domain aswell.
It seems like it's just the same as adding a windows PC to the domain - ie. the administrator account needs access to define the new computer object - but it doesn't look like the administrator account is used after that - although it does continue to show up in the web-interface - but I've tried eg. disabling the admin account we used - and ACS still continued to work.
Rather than use a normal admin account though just in case / to stop it looking odd in the web-interface, our AD administrators created a service account specifically for ACS to use to join the domain.
They created a new OU to contain the new computer objects - eg. Servers\ACS Appliances\
...and gave the service account delegated right to the computer objects in the new OU.
So since it only has access to that OU - I don't believe there's an issue with leaving the account enabled - but like I said - I don't think it's used apart from during the 'join' process - so you could disable it. I've never had to re-join the domain since the original join.
We did have some problems joining the domain though - despite that setup. I think our AD guys had to manually create the computer objects first (normally automatically created by the ACS joining) - and then "delegate control for the ACS service user to join computers in the target OU by creating a custom task to delegate" - I believe they used the 'Delegation of control wizard' in AD users and computers, selected the role account, 'create a custom task to delegate', 'only the following objects in the folder' - computer objects - create selected objects in this folder & delete selected objects in this folder, then Permissions - tick general and select 'validated write to DNS host name' / 'validated write to service principal name' / 'change password' / 'reset password' / 'read and write DNS host name attributes'.
>I'm not sure I understand the meaning of the the sentence: "If a user's AD group membership and attribute information is required for access policy, they must first be selected in the AD configuration." Could someone provide some clarity?
This isn't very clear is it - but I think this is trying to say that you need to select the things in AD you want to use before you can use them in the policy. ie. we're using group memebership (ie. a user has to be in a certain group in AD to get the correct access) - but you can't just refer to those groups from the policy - you need to select those groups from AD first - ie.
Users and Identity Stores > ... > External Identity Stores > Active Directory - Directory Groups tab - Select.
Then you can use them in the group mapping policy to map to an internal ACS group - which can then be used in the Authorization policy.
>"ACS 5.2 joins Active Directory (AD) directly and does not rely on a domain-joined Windows Server. ACS Remote Agent is not required."
Yes - I beleive ACS prior to 5.x required an agent installing on the AD DC - but now that is not the case as ACS joins AD natively. From some debugging we've done - it appears to use the 'CentrifyDC' linux packages - so it talks to AD natively as if it were a normal AD client.
AD integration is good - when you get it working! Look out for problems with ACS not obeying 'AD sites and services' policy - ie. it won't use the DC you want it to if you've defined AD S&S - it will connect to any DC in the domain - which is interesting if some of your DCs are behind firewalls like ours. Apparently this isn't supported - but there's a feature request in to add it - hopefully soon!
Hope that helps! Good luck!
