NAC External DB issue

[ajohnson]

I am trying to get NAC up and running. I have CTA loaded on a client. When trying to get access I get the following error on the ACS server

External DB account restriction, this is under the failed attempts log. On the CTA log on the client I get PEAP handshake success after the cert is verified then it shows EAP identity as the username that is logged into the client, the next message is a EAP failure.

It appears that it is trying to authenticate with the username of the client. Is this correct? On the ACS server under username for the failed attempt it shows as the username that is logged in as well.

The CTA and ACS are agreeing on the certificate process and it looks like it fails after that step.

Any ideas or more information on this error?

ACS 3.3(1) Build 16

CTA 1.0.53

[gfullage]

Whenever you get "External DB Acount Restriction" on ACS there's usually something wrong in the ACS config. The best way to troubleshoot this is to enable additional logging in the Failed Attempts log, and ACS will tell you pretty much what is wrong.

Under System Config - Logging, click on the Failed Attempts log, and in the Attributes table on the left, if you scroll down there's a ton of NAC-based fields. Add these into the table on the right, then try re-authenticating, and ACS will tell you exactly what the DB restriction is.

If you're not sure, report back here with the error and we'll help you out further.

[ajohnson]

I was able to get ACS to successfully check credentials. I removed all Mandatory Credential types and just had one local credential and I was able to get a healthy token.

I am now trying to use the Trend External policy server with this. I have enabled additional logging.

Under reason I am getting "A token was not returned from a policy. Database-configuration=NAC Policy=Trend" I am still getting External DB account restriction under Authen-Failure.

I have made sure that the SSL cert is the same between the Policy server and the ACS. Username and password has been checked on the Policy server and it is correct in the External DB.

Thanks for any more information

[pcomeaux]

Ok - I've run into this as well.

Here's some things to check:

1) Make sure the URL in ACS is similar to the following (just change the IP) http://192.168.1.X2:8081/antibody/cgi-bin/PostureRequest.dll?PostureRequest

2) Make sure the Username and Password used in the ACS config is configured on the Trend Server

3) Make sure for Forwarding Credential Types that you select Trend-AV on the ACS Server.

4) Be sure to save and submit all config changes on the ACS Server.

I've gotten caught on item #2 before and have seen a similar error message.

Here's what needs to be configured on the Trend Server:

1) Log on to the Trend Policy Server Console

2) Configurations--> Office Scan Servers --> add

3) Enter in the IP, the port number (8080), and select the policies to be used.

4) Click Save and Ok.

5) On left side, click summary then Sync with Office Scan and then ok.

Let us know if everything you have matches this and we can help you further.

thanks

peter

[ajohnson]

It turned out to be a SSL issue between ACS and the Policy server. The cert was on the ACS server, but I had to copy it again and it works. Policy server is working as it should.

Now the only issue that I am having is with the URL redirect. When using "show eou ip x.x.x.x" The URL field is getting the correct URL redirect, but from the client browser I dont get redirect. This is in clientless configuration. I get clientless authentication fine.

Now I understand it to redirect any website that you try to access..is this correct? Say I type in www.cisco.com in the browser, shouldnt it go to the URL redirect instead?

Thanks.

[pcomeaux]

I ran into a similar situation when URL redirects wouldn't work.

In order for a URL redirect to work, the user must be denied by the downloadable ACL for the URL redirect to work.

For instance, you might the default ACL on the interface as:

permit ip any any

And the ACL for the Unknown group should be similar to:

deny tcp any any eq 80

permit ip any any

OR

deny ip any any

If your ACLs are already setup this way or similar, let us know and we can dig deeper.

But like you, I experienced this problem until I adjusted the d/l'd ACLs to deny port 80 access to the users.

Hope this helps,

peter

[ajohnson]

I guess I was misunderstanding how the URL redirect works. From the client if I type in the IP of the router in the web browser the URL redirect works correctly.

I thought that anything the user would try to go to in the web browser would be redirected.

I even updated the ACL's like you suggested and this didnt seem to make a difference.

[pcomeaux]

Let's make sure we are on the same page.

I've deployed NAC at a high school where all the students and faculty have wireless enabled laptops.

The students should have Trend and CSA installed, if not they should not be allowed access to the internet. So we placed a router to enforce NAC as a L3 Hop before the internet firewall.

On this router, I have a default ACL on the interface of permit IP any any. I am using Healthy, Checkup (missing CSA), Quarantine (out of date Trend or disabled) and Unknown.

If the students fall into the Unknown, Checkup, or Quarantine group, the downloadable ACL for the student is:

deny tcp any any eq 80

permit ip any any

If the user is Healthy, the ACL remains permit any any.

I also specify for the Unknown, Checkup and Quarantine groups a unique URL for the students to be redirected to. This works well, so no matter what URL the students attempt to access (www.google.com, www.cnn.com, www.rice.edu, etc), they are resolved to an internal web server. I have this working for about 800 users.

Does this sound like what you are trying to do?

thanks

peter

[ajohnson]

On a much smaller scale, yes.

Like I said the only way the URL redirect works is if on the client I try to go to the IP of the NAD. If I try to go to any other IP it doesnt work. This isnt that big of an issue. The client will just have to type in the URL and go there to install the Trend Client.

[pcomeaux]

Ok - cool.

If you would like, please post or e-mail (pgc@cisco.com) the output of a client experiencing this of a show eou ip CLIENT-IP and the corresponding dynamic ACL that is detailed in the above show command. This will help us dig deeper.

thanks!

peter

[pcomeaux]

Here's some places to check based on my several NAC installations:

1) External User Databases --> Unknown User Policy

make sure your NAC database has been included in the databases to check

2) External User Db --> Db Config --> NAC

make sure your Mandatory Credentials for the NAC database are not too restrictive

e.g. if you include a certain AV as a Mandatory Credential and the client does not have AV installed, you will receive a "External DB account Restriction" type message.

Let me know how these look and we can continue looking further into your config.

thanks

peter