cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements
Announcements
Choose one of the topics below to view our ISE Resources to help you on your journey with ISE

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.

434
Views
0
Helpful
3
Replies
Highlighted
Beginner

How to eliminate the risk when the non-compliant computer access the AD?

Dear All,

Background: It is wired dot1x with machine authentication and posture assessment deployment. My customer has a requirement: network access for computer (including domain/ non-domain) should be restricted before authentication and posture assessment.


I would like to use static port ACL to restrict network access before authentication and posture assessment complete. once the computer passes the authentication and posture assessment, the switch will download the dACL to the port, so that the user can access the production network. 

Questions: Since the user login the computer (with no windows account cache) using AD account. The static port ACL should allow the traffic between computer and AD. Hence, when the computer does not pass compliance check, it can access to the AD. How to eliminate the risk when the non-compliant computer access the AD?

Best regards,

Jason Chu

1 ACCEPTED SOLUTION

Accepted Solutions
Highlighted
VIP Advocate

Having gone down this road many times you need to reset your customer's expectations and clearly explain to them how posturing actually works.  Authentication and Posturing are separate activities.  Posture happens very late after the login process has completed.  If you start restricting access, you are going to break pre-login access, login access, login scripts, drive mappings, etc.  If you start putting together the ACL to allow this stuff to work you will be just short of "permit ip any any".

You posture devices that have authenticated, so you know at some level these are trusted devices which takes the risk down a bit.  My philosophy is in the unknown state the restrictions need to be noticeable but not detrimental.  I usually block Internet access in the unknown state but allow full Internal access.  Again these devices have successfully authenticated.

If the device proves to not be compliant then you can slam the door shut.

My 2 cents.

View solution in original post

3 REPLIES 3
Highlighted
Contributor

switch config : ip access-list extended (NAME)

permit udp any any eq bootpc bootps (dhcp)

permit ip any host 10.10.10.10 (ise host IP adrees)

I think maybe this will be enough to can restrict.

Highlighted

That ACL will break all sorts of things. Would definitely not go that route. Again you need to allow prelogin, login, login scripts, etc. to run before posture status is reported.

Paul Haferman

Office- 920.996.3011

Cell- 920.284.9250

Highlighted
VIP Advocate

Having gone down this road many times you need to reset your customer's expectations and clearly explain to them how posturing actually works.  Authentication and Posturing are separate activities.  Posture happens very late after the login process has completed.  If you start restricting access, you are going to break pre-login access, login access, login scripts, drive mappings, etc.  If you start putting together the ACL to allow this stuff to work you will be just short of "permit ip any any".

You posture devices that have authenticated, so you know at some level these are trusted devices which takes the risk down a bit.  My philosophy is in the unknown state the restrictions need to be noticeable but not detrimental.  I usually block Internet access in the unknown state but allow full Internal access.  Again these devices have successfully authenticated.

If the device proves to not be compliant then you can slam the door shut.

My 2 cents.

View solution in original post

Content for Community-Ad