I can't tell if this is better suited for Networking or Systems.
I'll start here until I get berated.
Here's the gist of my problem:
I'm setting up a new ACS group for our Technicians to be able to make VLAN changes on the L2 devices.
The problem is that I can't get the test account to authenticate.
Active Directory:
I created a new user account in Active Directory called "dummy" and added it to a new Active Directory Security Group called NetworkTech.
Both the Group and the Account are located in our IT Dept OU, so Group Policy is inherited the same way my personal account would be.
ACS:
I added the new Group Location into the ACS External Identity Stores.
I created a new Authorization Group under Access Policies for the Technicians and linked it to the AD Identity (wide open)
I configured the new Group to simply use the same Shell Profile and Command Sets that my account uses, just so that it's configured with known-good policies.
It will not authenticate.
When I run the Authentication Report, it simply tells me that the Default Shell Profile of DenyAccess was chosen, but I need something more granular that tells me WHY the default policy was chosen.
If I add the Active Directory account to a different Active Directory Security Group, the account can Authenticate.
For Example, if I add the "dummy" account to the "DomainAdmins" Security Group in AD, the account successfully authenticates.
So basically, when the AD user account is part of the new Network Technician AD Group, it won't authenticate via TACACS.
When I move the account to a different AD Group, it will authenticate.
Does anyone have a tip for what to potentially check?
The new AD group has been moved to the same OU that my account is in, so all Group Policies are inherited just the same as my account.
I've combed through ever ACS setting, every GPO link, and all the articles I can find, and just can't seem to pinpoint an issue.
Possible a Firewall restriction, although this seems unlikely ... ?
No comments:
Post a Comment