ACS 5.1 User Add

[rmeans]

My ACS 4.0 has roughly 3000 users most of which are assigned to the default group.  99% of the 3000 users authenticate against the Windows database.  ACS 4.0 only stores the username (no local passwords).  The migration tool (to ACS 5.1) inserted the 3000 users into the Internal Identity Stores – Users section.  I am assuming this is correct.  When I create a new user (Internal Identity Stores – Users section) one of the required items/entries is a password.   I don’t want to enter a password.  I want the user to authenticate against Active Directory.  Is there another place where users should be added?

[Nicolas Darchis]

If you authenticate your users against Active Directory, you don't need to add them at all to ACS ! Not sure if you've been doing is uselessly in the past.

If ACS 5 is connected to AD, then you don't need any user in the internal user store. It just uses the ones on AD.

Nicolas

[rmeans]

We are getting ready to migrate from ACS v4.0 to v5.  ACS 4.0 requires the user be defined in the database.  During our tests, we migrated the user database.  Based on your comments, there is really no need to migrate the user database.  We have a couple of local accounts defined with ACS.  We can manually migrate these user accounts.

With ACS 5, I will want to define access policies.  Contractors have access to remote access VPN.  Company staff have access to wireless.  Etc.  I am guessing the policies defined with ACS will need to match groupings defined with Active Directory.

Any links or white papers you can share.

Thanks for the help

[Nicolas Darchis · Accepted solution]

I guess that what you had done was to enter the users in ACS 4 so that you could add properties and attributes to them.

Here you can define policies with group mapping. You can define conditions such as "if user group in AD = xxxxx then I return this type of profile or attributes".

http://www.cisco.com/en/US/docs/net_mgmt/cisco_secure_access_control_system/5.2/user/guide/access_policies.html#wp1064991

[rmeans]

Good info.  Thanks again.

[Vinay Sharma]

Hello Rick ,

I am glad Nicolas was able to provide you the information. Just to inform you that Nicolas is presentaing a LIVE webcast on Cisco Wireless CleanAir.

https://supportforums.cisco.com/videos/2296

Please register and get more info from Nicolas.

Thanks,

Vinay Sharma

Community Manager - Wireless

Cisco Support Community

[jrabinow]

Just want to add a couple comments to all the info above. There are two reasons where I have seen user

- cases where want to take the password from AD but want to restrict the set of users that can access the system. So only those in intrnal user database can access with password from AD (or other db). In this case a password is defined but is not in fact used. This approach is not very scalable and should be avoided if possibel to drive soley off the data in AD

- cases where want to use additional attributes in policy decisions that are not stored in AD. for example, can't determine level of access solely by AD group and so can define additional internal user attributes for users. Again ideally should be driven off AD data but can be a workaround where the data does not exist