Cisco ACS authenticaion across trusts

Which version of ACS do you have?

ACS 5.2.6
Active Directory Native 2003

Ok, you can use the AD method to connect to one domain, but for multiple domains (trusted or not) you need to use LDAP for the second, third, nth domain thereafter.

Is it possible to have ACS connect to one domain, then use domain trusts to have that AD check the other domains and return the authentication to ACS?

We are having the issues specifically working with our wireless lan controllers.

We use MSCHAPv2 and both TLS and EAP, which doesn't allow for multiple LDAP sources.

See table B-5 in the following page: http://www.cisco.com/en/US/docs/net_mgmt/cisco_secure_access_control_system/5.2/user/guide/eap_pap_phase.html#wp1014889

That should work, providing you have a two-way trust.

The ACS will query an available DC in the domain to which it is joined, then the DC should forward the request to a DC in the appropriate domain if required.

I have validated our two-way trusts.  I have selective authentication enabled, and have an external user in a local group that is defined in our ACS.  The error we get in ACS is a "subject not found."

What conditions have you set?

The access policy has three conditions:
-Membership in a specific AD group.  We have added external users as members of our group.
-EAP authentication
-End station filter

So you can't match a policy if your user is in a different AD group to one you specified, as you can't specify groups in remote domains.

Can you screenshot the policy?

I have attached a couple screen shots.
pic1.jpg
pic2.jpg
pic3.jpg

Can you post the AAA RADIUS Authentication log which shows the failure (click on the looking glass)?

Error message attached.
pic4.jpg

Ok, go to Users and Identity Stores -> External Identity Stores -> Active Directory, then click on the Directory Groups tab.

Click Select, then in the Search Base DN box, can you set the remote domain as the Base DN?

So, if your local domain is mydomain.local, and your remote domain is myotherdomain.local the Base DN would be changed:

from:
DC=mydomain,DC=local

to:
DC=myotherdomain,DC=local


Then click Go...

Do you see security groups from the remote domain?

We get no results when setting the other domain as the base dn.

Hmmm that should work.  Can your ACS 'see' the remote domain controllers?

I will be back in the office tomorrow and will check, but I believe we can ping all the domain controllers.

Yes, our ACS server can ping the host name for the domain controllers in the remote domains.

I would try removing all access conditions and just use the default authorization rule with the permit all result to ensure you can actually receive a successful authentication response from the AD.

ACS is reporting "subject not found" that it can't find the remote user, not a permission denied error.

Can you check the Authentication details to see which Identity Store was used to locate the user?

ACS only has one identity store, our internal AD.  See my previous post for a copy of the error. #a39026712

There must be an issue between your DCs.  I am not understanding why you can't query groups in your remote domain if the trust is working both ways.

Can you confirm that a user in your primary domain can authenticate properly?

Yes, our primary domain users are logging in without any issues. We are able to authenticate cross forest users to other AD services (such as Exchange) that do not go through ACS.

Do you have anything in the event logs on your DCs when you try to authenticate a user in the remote domain via ACS?

Found something in the remote domain's log:
Event ID: 675 (Account Logon)
Failure Audit
Pre-authentication failed:
User Name: test
User ID: %{SID HIDDEN}
Service Name: krbtgt/domain
Pre-Authentication Type: 0x0
Failure Code: 0x19
Client Address: 10.x.x.x

That is a Kerberos problem between the two domains.  The 0x19 failure code indicates that pre-authentication failed because of a bad password, or it can be because of one of the reasons listed here:

http://www.eventid.net/display.asp?eventid=675&eventno=62&source=Security&phase=1

Check the time on the ACS is within 5 minutes of the time on the remote DCs, and that all date/time settings are correct.  If possible, let your servers and your ACS sync with an external time source.

Both domains use the same satellite time server to sync clocks over NTP.  I have verified the password is correct.

Ok, one of the issues in the link above must be the reason why you can't query the remote domain from AD, and why the user authentication fails.  The ACS server needs nothing else other than to be joined to the AD domain in order to pass authentication requests.

Both domains are functional 2003 mode.  The remote domain only has 2003 DCs and the local domain has a mix of 2008 and 2003 DC's.  According to that article, this error would be a false report in a 2003 forest.

Status update - We are now seeing errors in ACS stating that the remote user failed to provide a correct username and password, even though I have verified it is correct.  We are working with Cisco support to resolve this issue.

IIRC you saw this error on your DCs already.  It is 100% a trust issue if you are seeing the same errors on the ACS.

We are still working with Cisco support, but do not have a solution yet.

We have not been able to resolve this issue yet, but we are starting to see some other domain trust issues coming up, which points us in that direction.
Thank you for your assistance.