This community is for technical, feature, configuration and deployment questions.
For production deployment issues, please contact the TAC! We will not comment or assist with your TAC case in these forums.
Please see How to Ask the Community for Help for other best practices.
This is an opportunity to learn and ask questions about how to configure and troubleshoot the new Cisco Secure Access Control System (ACS) 5 Installation.
Ask questions from Monday, May 11th, 2015 to Friday, May 22, 2015
Javier Henderson has been a customer support engineer with the Security Team, specializing in AAA technologies, since 2004. In addition to supporting Cisco customers, he has delivered training to other teams on various AAA products. Javier attended Buenos Aires University and holds CCNA and Checkpoint certifications.
**Ratings Encourage Participation! **
Please be sure to rate the Answers to Questions
We are currently deploying Cisco ACS v5.6 to authenticate wireless lan users via their Microsoft Active Directory 2012 domain accounts and computers.
During the integration of ACS to MS AD2012, we are having hard time in joining the two device.
I know that we usually request the "Domain Admin" to join the ACS to Active Directory, but this time their Microsoft System admin is not convinced to give us the "Domain admin" account and challenge my team to provide the exact privilege needed instead of the domain admin rights.
My question is, will the "Domain User" work with one of these privilege?
A user with "domain user" privileges will not be able to complete the steps outlined in the ACS documentation (i.e., the text you included in your question).
Note that once ACS has joined the domain, the credentials used for that step can be disabled by the AD admin, as they will not be needed again until ACS needs to join the domain again (which would only happen if you manually un-join the AD domain via ACS configuration change).
We are just upgrading to ACS5.7 on a virtual machine and it has locked up !!!
we have been waiting about an hour and still no response
Should we reboot the vm or is there maybe a virtual 'button ' on the vm console ?
For this problem, it will be best to open a TAC case, we will need to look at ACS installation logs to determine root cause.
Another problem i am afraid .. our other acs has failed to authenticate on radius but works fine on tacacs and it looks like ad is working
This means with the other one locked out in 5.7 we are in trouble
Why would radius not work
The error we are recieving is 'problem 24444 active directory operations has failed because of an unspecified error in the acs'
I looked this up earlier and it suggested a problem with ms server 2012 r2 but as i understand we are using ms server 2008 any ideas /
We will need to look at ACS debug logs to troubleshoot your AD problem. On the CLI, execute the following commands to enable debug on the runtime and AD services:
# acs-config (authenticate with GUI credentials when prompted)
(acs-config)# debug-log runtime level debug
(acs-config)# debug-adclient enable
Then after the problem has been seen again, download a support bundle including the system and debug logs, and look at the AD activity log for clues. We can help you further on this if you could open a TAC case, or post your logs here (though, be mindful of sensitive information).
We are currently deploying ACS 5.6 utilizing AD as our external identity store. I have configured a Shell Profile and Command Set with full level 15 access and full access and I am able to log into our test Cisco 2960 switch running IOS version 15.0(2)SE6 successfully utilizing tacacs+ through the Cisco ACS. However, when I log into the switch I am not given access to the privileged mode and it gives me the error message "Command Authorization Failed" whenever a command is entered.
When I go to my Device Administration Authorization Policy, the Rule I created with a Shell Profile of level 15 and Command Set Full Access has no hits. All authorization attempts are hitting the Default rule which is denying access. I have deleted and redone the Shell Profile, Command Set and Authorization Policy with the same results. Do you have any ideas of what could be causing this?
It looks like the criteria used for the authorization policy rule that you created is never met. Look at the detail of the authentications and authorizations for your test user, it will tell you all of the attributes that ACS gathered from your AD identity store. Then compare that with the criteria you configured for your authorization rule, to see what's missing.