Clean Access L3 OOB Timeout Configuration

Hey All,
Thanks for the help so far with Clean Access. We are up and running L3 OOB w/ ACLs in our test environment and all is working as expected. I have a question that doesn't seem to have been posed yet. I want to create a rule that will kick a user off of their user VLAN after being logged in for X number of hours. Our policy states workstations are to remain off, but that rarely happens and these workstations should be placed back into the auth VLAN if they are not powered off. I've attempted to set the timeout setting on the CAM, but this did not cause the user to be moved back to the auth VLAN. In a L3 OOB multi-hop deployment, how can this be achieved?
-Mike
http://cs-mars.blogspot.com

Check out the manuals.
What most people do is clear the certified device list at say 02.00am in the morning so the next day, posture assessment can occur again. It's one of the trade-offs for doing L300B. There are kick user commands and scripts you can crete and run.
Cisco are looking into ways of clearing certified users on logout but this is not committed yet.

Similar Messages

Clean Access Agent Link Distribution

Hi Guys,
I'm installing Clean Access VG OOB. Problem is that I get the user to login via CAA, if they fail the AV check (can have any AV vendor) then they are pushed off to URL to download the corporate AV software. Once the software is installed the CAA doesn't offer the option of clicking the next button it just sits there with the temporary access timer ticking away. If I cancel then re-login the client is then logged in successfully as he has passed posture assessment. I have tried a seperate installation of CAA via msi file but still getting the same problem.
Any ideas?

Hi,
Just found out this is what's suppossed to happen apparently

Clean Access Agent fails to login "normal" user but allows "Administrator"

Hello,
I have the following problem. When a user tries to login using clean access agent (OOB+VG), the login process fails. When an administrator tries to login, the process works.
What could be the problem?

By the login process failing I mean that the machine is not assigned an IP address by the DHCP server

Cisco Clean Access OOB with virtual gateway

I have set the clean access OOB virtual gateway mode, i put managed subnet one of unused ip with unauthenticated vlan,some of the pc running with dhcp so i put ip refresh after successful authentication (this working fine), but some of them running with static so i cannot refresh the ip address,
after authentication through clean access clean access manager changing Unautheticated vlan(44) authenticated vlan (4), but i can't access internet and any other application through network (even with static ip and dhcp (if i put refresh dhcp ip i can) ), in pc arp cache i can see the orginal gateway mac address if i clear the arp cache with arp -d command the moment it start working how can solve this issue please help me guys
thank you

This document describes how to configure the syslog settings in order to log the events to an external server in the Cisco Network Admission Control (NAC) Appliance, formerly known as Cisco Clean Access (CA).
http://www.cisco.com/en/US/products/ps6128/products_tech_note09186a008085d6e9.shtml

CISCO CLEAN ACCESS AGENT ALWAYS POPS-UP EVEN ALREADY AUTHENTICATED

Hello,
Just wonder why clean access agent always pops-up even already authenticated. Please how can i eliminate those multiple pops-up?
thank you and best regards,
Edwin

Hi:
I have the same issue. Would you please tell me what you did exactly?
I am using OOB VGW mode.
NAC version is 4.7.2
Switch configurations:
snmp-server community RO RO
snmp-server community RW RW
snmp-server location LOCATION
snmp-server contact CONTACT
snmp-server enable traps snmp linkdown linkup
snmp-server enable traps mac-notification change move threshold
snmp-server host CAM_IP version 2c RW mac-notification snmp
mac address-table notification change interval 0
mac address-table notification change
mac address-table aging-time 3600

Clean Access Agent can't popup

Hi, we setup a CAS and CAM in L2 OOB virtuil gateway and the switch is a 3560 using SVI and L3 for routing. We can authenticate using web agent but there is a problem when using a Clean Access agent. I have configured the discovery host using the ip address of the CAM but the login doesn't popup. I changed the discovery host of the ip of the server and tried reinstalling the access agent but login doesn't popup. Do I need to reboot the server when i changed the ip of the discovery host?What do i need to configure on the CAM or CAS?

For L2 or L3 deployments, the Clean Access Agent will pop up on the client if "Popup Login Window" is enabled on the Agent and the Agent detects it is behind the Clean Access Server. If the Agent does not pop up, this indicates it cannot reach the CAS.
To Troubleshoot L2 Deployments:
1. Make sure the client machine can get a correct IP address. Open a command tool (Start > Run > cmd) and type ipfconfig or ipconfig /all to check the client IP address information.
2. If necessary, type ipconfig /release, then ipconfig /renew to reset the DHCP lease for the client.
To Troubleshoot L3 Deployments:
1. Check whether the Discovery Host field is set to the IP address of the CAM itself under Device Management > Clean Access > Clean Access Agent > Installation | Discovery Host. This field must be the address of a device on the trusted side and cannot be the address of the CAS.
2. Uninstall the Clean Access Agent on the client.
3. Change the Discovery Host field to the IP address of the CAM and click Update.
4. Reboot the CAS.
5. Re-download and re-install the Clean Access Agent on the client.
Note The Login option on the Clean Access Agent is correctly disabled (greyed out) in the following cases:
â¢For OOB deployments, the Agent user is already logged in through the CAS and the client port is on the Access VLAN.
â¢For multi-hop L3 deployments, Single Sign-On (SSO) has been enabled and the user has already authenticated through the VPN concentrator (therefore is already automatically logged into Cisco NAC Appliance).
â¢MAC address-based authentication is configured for the machine of this user and therefore no user login is required.

Network Error: Clean Access Server could not establish a secure connection to Clean Access Manager

Hello everyone
I am implementing a failover solution of NAC in OOB VG version 4.8, I have 2 CAS and 2 CAM.
The Error I am getting is when I connect to both IP address and the FQDN of the CAS.
===========
Network Error:
Clean Access Server could not establish a secure connection to Clean Access Manager at camsrv3.cadivi.gob.ve.
This could be due to one or more of the following reasons: 1) Clean Access Manager certificate has expired 2) Clean Access Manager certificate cannot be trusted or 3) Clean Access Manager cannot be reached.
Please report this to your network administrator.
==========
For the CAM's I use this names camsrv1 and camsrv2. then generate a CSR in the camsrv1 with the name camsrv3.mycompany.com corresponding to virtual ip and it exported to camsrv2, Install the CA certificate of the company and everything works perfect.
This is the failover configuration
CAM:
Primary:     10.1.206.248 camsrv1.mycompany.com
Secondary: 10.1.206.249 camsrv2.mycompany.com
Virtual:       10.1.206.250 camsrv3.mycompany.com
Then I do exactly the same steps for the CAS's and this is the failover configuration:
Primary:     10.1.216.248 cassrv1.mycompany.com
Secondary: 10.1.216.249 cassrv2.mycompany.com
Virtual:       10.1.216.250 cassrv3.mycompany.com
Then I add the certificate of CAM in the CAS on the tab "Trusted Certificate Authorities" and vice versa.
The communication between all the CAM´s and CAS´s is correct (Primary, Secondary and Virtual). I can ping the IP and the FQDN and I can also manage the CAS through the CAM.
I verify that the time was right in the CAM and the CAS and all good up there.
Appreciate your help
Eduardo Navas

Eduardo,
Bump up the CAS/CAS communications logging on both the CAS and CAMs, and then look in the log files for clues.
On CAM they live in /perfigo/control/tomcat/logs and on CAS in /perfigo/access/tomcat/logs
HTH,
Faisal
If you find this post helpful, please rate so others can find the answer easily

Clean Access HTTP redirect wrong after IP address change

Hi,
Wondered if anyone had seen this:
We have a Clean Access server running in VGW mode for VPN traffic, after a redesign the IP address has changed (the trusted and untrusted are the same).
Unfortunately when a user logs in it still uses the old IP address in the HTTP redirect, this has been confirmed by looking at the HTML source.
Apart from that it looks fine, new SSL certificate etc.
Any ideas apopreciated, thanks.
Jim.

For all deployments, if planning to configure the Clean Access Server in Virtual Gateway mode (IB or OOB), do not connect the untrusted interface (eth1) of the standalone CAS or HA-Primary CAS until after you have added the CAS to the CAM from the web admin console. For Virtual Gateway HA-CAS pairs, also do not connect the eth1 interface of the HA-Secondary CAS until after HA configuration is fully complete. Keeping the eth1 interface connected while performing initial installation and configuration of the CAS for Virtual Gateway mode can result in network connectivity issues.
When setting up a CAS in Virtual Gateway mode, you specify the same IP address for the trusted (eth0) and untrusted (eth1) network interfaces during the initial installation of the CAS via CLI. At this point in the installation, the CAS does not recognize that it is a Virtual Gateway. It will attempt to connect to the network using both interfaces, causing collisions and possible port disabling by the switch. Disconnecting the untrusted interface until after adding the CAS to the CAM in Virtual Gateway mode prevents these connectivity issues. Once the CAS has been added to the CAM in Virtual Gateway mode, you can reconnect the untrusted interface.
Administrators must use the procedure mentioned in the below URL for correct configuration of a Virtual Gateway Central Deployment:
http://www.cisco.com/en/US/docs/security/nac/appliance/configuration_guide/418/cas/s_instal.html#wp1045874

NAC Clean Access Authentication not doing anything

Hi!
I have instaled an NAC solution, using oob with acl's.
When i get to the Clean Access Authentication page, using the right user and password, or an worng one, the page keeps showing up, requesting to authenticate and without any errors.
Did this happened to anyone?
TKX
Miguel

Hi Miguel,
The configuration so far looks OK.
The only test I would suggest would be to keep the clients on a vlan/subnet different from the CAS untrusted IP's subnet.
I am telling this because usually we have the following:
1. Clients are being assigned to a trusted vlan/subnet, for which we have an IP address configured in the CAS as a managed subnet and assigned to that vlan.
2. In this case, clients are getting an IP on the same subnet as the untrusted interface of the CAS, which is not doing any kind of vlan tagging.
As a further test, you could for example keep the clients on a subnet that is not the same as the one for the CAS untrusted interface and add the corresponding managed subnet for that client vlan.
Alternatively, you could configure the CAS untrusted interface to tag traffic on the same vlan where clients are getting an IP, but this is usually more tricky.
This suggestion comes from the fact that what you are experiencing (clients continuously re-prompted for authentication) is often seen when the CAS is not configured for the proper managed subnets.
One more thing to verify is that the user being authenticated is not falling under the Unauthenticated Role.
This could happen for example when configuring an Authentication Provider with the default role as Unauthenticated and mapping rules: if mapping rules are not triggered correctly, the default Unauthenticated Role will be assigned and the client will keep getting the authentication prompt.
If these further points didn't show any improvements, I would recommend to keep following this through a TAC Service Request:
http://tools.cisco.com/ServiceRequestTool/create/launch.do
Regards,
Fede
If this helps you and/or answers your question please mark the question as "answered" and/or rate it, so other users can easily find it.

Clean Access Server could not establish a secure connection

I have a OOB Real IP GW setup on v4.1.2
I seem to have a problem with the CAS connecting to the CAM although I have added the CAS to the CAM and can manage the CAS from the CAM.
I noticed while troubleshooting client authentication that the client was not being redirected to the logon web page and it had full access to the trusted network from the untrusted authentication vlan. I eventually figured out that if I change the CAS Filter Fallback method from Allow to ignore then it tries to authenticate the client. However the fact that the fallback is activated tells you that something is not right.
I have 2 problems:
A) The clients web page is redirected for authentication but it only lists the domain name in the URL and not the hostname or host IP. In the lab I do not have a DNS server and it would not help as it does not include the hostname in the URL anyway. How do I fix this or perhaps it's related to the 2nd problem.
B) When I manually change the URL by replacing the domain name with the IP of the CAS (untrusted OOB Real IP GW) then I get the following error message when logging on:
Network Error:
Clean Access Server could not establish a secure connection to Clean Access Manager at mydomain.com.
This could be due to one or more of the following reasons: 1) Clean Access Manager certificate has expired 2) Clean Access Manager certificate cannot be trusted or 3) Clean Access Manager cannot be reached.
Please report this to your network administrator.
I would guess the culprit is No 2 but surely the system can run on self signed certificates? I have an NTP server so time is in sync. I have even tried regenerating the cetificates on the CAM
& CAS.
Any ideas?

To overcome problem B, I regenerated the SSL Certificates using the host IP address instead of the name for all the CAM & CAS appliances. This seems to have resolved this problem.
I also SSH'd from each of the CAS's to each of the CAM's from the CLI and it then prompts to permanently store the certificates. I'm not sure it this was necessary though.

Plse...help me on the communicating between CLEAN ACCESS MANAGER and Switch 3560E-24Ps by snmp

Dear All,
I try to configure in both Clean Access Manager and Switch 3560E-24Ps on SNMP Version 2 protocol but I can't make it working together (For CAM and Switch 3560G-48Ps I can do that). Plse give me any suggestion to solve that problem. All configuration is as below:

http://www.cisco.com/en/US/docs/security/nac/appliance/configuration_guide/412/cam/412_cam_book.html

Clean access rules and Windows service pack 3

I am having a small issue with our Clean Access Manager blocking any Windows XP computer that has service pack 3 installed. The main failure it is giving in the reports is this
Failed Checks:
pc_Windows-XP-SP2, Registry Check [\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\CSDVersion contains Service Pack 2]
pc_Windows-XP-SP1, Registry Check [\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\CSDVersion contains Service Pack 1]
The key that is there when sp3 is installed is this:
\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\CSDVersion contains Service Pack 3
I have verified that pc_Windows-XP-SP1 and pc_Windows-XP-SP2 are there as well as created a check for service pack 3 eric_pc_Windows-XP-SP3 and added the check to the rules governing windows updates for XP pro/home and windows media edition. But for some reason they are not taking effect. The CAM is running version 4.1.3.1 and the the CAA is version 4.1.3.2. Any assistance would be greatly appreciated.
Thank you,
Eric

Here is the configuration guide for the Clean Access Manager which will help you :
http://www.cisco.com/en/US/docs/security/nac/appliance/configuration_guide/413/cam/m_instal.html

Clean Access and Windows 2003 Server

I am trying to install the Clean Access Client on a VM running Windows 2003 Server. When I connect to our customer's network the VPN client appears to connect properly and I see the Clean Access window. Then it all seems to fall over. My customer tells me I should see a blue window with a red OK button on it but I never see it. As a result I never get completely into the network. Is this because I am running this on Windows 2003 Server or should I be looking at something else? Can this run in a Virtual Environment and on 2003 Server?

I work it out partially by myself:
1)
(excuse me, I meant "kinit and Krb5LoginModule" not "kinit and kinit.exe").
Krb5LoginModule seems to work now (with TCP). The output is:
KRBError:sTime is Tue Jun 01 17:13:51 CEST 2004 1086102831000
suSec is 945761
error code is 52
error Message is Response too big for UDP, retry with TCP
realm is SSOTEST.RTC.CH
sname is krbtgt/SSOTEST.RTC.CH
KrbKdcReq send: kdc=rtcnt978.ssotest.rtc.ch TCP:88, timeout=30000, number of retries =3, #bytes=232
DEBUG: TCPClient reading 1496 bytes
KrbKdcReq send: #bytes read=1496
KrbKdcReq send: #bytes read=1496
EType: sun.security.krb5.internal.crypto.DesCbcMd5EType
KrbAsRep cons in KrbAsReq.getReply sso_testuserCommit Succeeded
Which is what I want (it tries first with UDP, then the KDC says the TGT is too big for UDP and the client tries again with TCP)
2)
I still have the error :-(

Help with Clean Access Architecture

Hello All,
I wanted to engage some of the NetPros out there about designing our Clean Access architecture. We purchased 4 3140s (2 x CAMs w/ FO, 2 x CASs w/ FO). The goal is to use Clean Access to validate select areas of our head quarters, along with validate users in a remote location.
The HQ part of the design I can understand without issue. It's when we begin to deal with the remote office that I become uncertain about the design. The remote office is MPLS connected to HQ (L3 multi-hop). We want users in the remote office to also be L2 authenticate to the Clean Access cluster at HQ. Across MPLS this does not appear to be straightforward. We'd like to do a L2 deployment, but from what I've read this will require using L2TPv3 at the remote office to "tunnel" the VLANs from HQ to remote and vice-versa. My fear is that now the default gateway for the remote clients is the HQ Clean Access cluster. Therefore... all traffic will be "switched" across their WAN link. This becomes and issue as the remote office has local Windows domain controllers for faster file access on another VLAN... and in this scenario it sounds like the workstations would have to travel across the L2TPv3 tunnel to HQ to just have to go back across the tunnel to the remote office for file access. Sounds slow!
Does anyone have recommendations as to how to design this centralized, L2, OOB architecture. In my mind I would want the clients attempting authentication to the switch... switch forward to the CAS... CAS validates posture and passes down necessary VLAN to switch. All VLAN'ing and switching is kept remote. We operate all 3750 switches... so our infrastructure can work with NAC. Sorry for the long post, just wanted to try to explain the requirements. Thanks for the help.
-Mike
http://cs-mars.blogspot.com

Hi Mike -
Very good questions. You definitely do not need the L2TPv3 across the WAN to control the ports at the remote site.
The CASs can be deployed L2 In-Band (IB), L3 In-Band (IB), L2 Out-of-Band (OOB) or L3 Out-of-Band (OOB).
L3 OOB can be used to control the switches at the remote sites. A 2nd vlan is required for the remote site to serve as the authentication vlan. All ports start off on this Auth Vlan when a user plugs in.
The user receives an IP Address on this Auth Vlan and the local L3 device is the GWY. The L3 device should have ACLs to protect the rest of the network from this Auth Vlan. The only permit entries in the ACL should let the users get to CAS and the remediation servers. Using a network like 192.168.x.x and varying the 3rd octet on a per-site basis simplifies the ACLs if you are using the 10.x.x.x as your internal addressing. The ACLs should be places on all the MPLS routers to protect the production network from the Auth network.
Once the user proves trustworthy, the Clean Access changes the vlan on the switch to the production/normal vlan and the user has complete access as before.
CASs can be either one of the 4 roles (L2 IB, L3 IB, L2 OOB, L3 OOB) when they are added to the CAM.
If you plan to use L2 OOB for your HQ and L3 OOB for the remotes, you may need to add 1 more CAS pair to your architecture.
We have some great diagrams that the Clean Access product team have put together that will illustrate this architecture to you.
Your local SE / CSE should be able to provide this to you.
Let us know if you have any follow up questions.
Hope this helps.
peter

Smartcard authentication for Clean Access SSO

Is anyone doing smartcard authentication into clean access via SSO? I have an issue where the UPN is not the username and the domain suffix is different from the AD domain so the agent is appending @domain.com to the $user$ variable and so it is failing to authenticate.

Did you run KTPASS correctly?
I had the same problem, (very undocumented 'feature', I would say) the KTPASS command must be run slightly different when running against a DC, versus running it against a AD Domain.
For Domain Authentication:
ktpass.exe -princ cleanaccess/domain_in_lower_case.co.za@DOMAIN_IN_UPPER_CASE.CO.ZA -mapuser cleanaccess -pass mypassword -out c:\cleanaccess.keytab -ptype KRB5_NT_PRINCIPAL +DesOnly
For AD Server Authentication:
ktpass.exe -princ cleanaccess/SERVERNAME.domain_in_lower_case.co.za@DOMAIN_IN_UPPER_CASE.CO.ZA -mapuser cleanaccess -pass mypassword -out c:\cleanaccess.keytab -ptype KRB5_NT_PRINCIPAL +DesOnly
NOTE: SERVERNAME need to be exactly as indicated under My Computer > Properties. (ie, correct UPPERCASE and lowercase letters in the right places)
Another thing to look out for is the cleanaccess AD account you have created, make sure that the display name matches the account name, and do not specify anything for the Firstname, Lastname fields. This seems to break things ans gets the authentication to fail for some reason.
O, and if you have set up the account at first for DC Server Authentication, delete it and recreate it for the AD Domain Authentication, because that breaks it too, when you run the KTPASS.EXE again.
Another thing, try using ADSSO without the lookup account configured to see that the machine authenticates first, then ad the Lookup Account, maybe the problem lies there.
Hope this helps.

Clean Access L3 OOB Timeout Configuration

Similar Messages

Maybe you are looking for