04-26-2017 01:08 AM - edited 02-21-2020 10:32 AM
Hi,
I'm quite new to the system and i'm currently installing Cisco ISE 2.1. I've tried to connect 1 windows client (added to the domain) to ISE using the default policy. My authentication order from the switch is dot1x then Mab then WebAuth but when the client tried to authenticate using dot1x ISE receive an error (12321 PEAP failed SSL/TLS handshake because the client rejected the ISE local-certificate). Then the windows client will successfully authenticate as MAB instead of dot1x.
Any suggestion or any missing configurations needed to authenticate windows client using wired 802.1x?
Also, what is the correct entry for cts sxp commands?
Switch configuration:
!
logging monitor informational
aaa new-model
!
!
aaa authentication enable default enable
aaa authentication dot1x default group radius
aaa authorization network default group radius
aaa authorization auth-proxy default group CiscoISE
aaa accounting auth-proxy default start-stop group CiscoISE
aaa accounting dot1x default start-stop group radius
!
!
!
aaa session-id common
!
!
ip dhcp snooping vlan 51
no ip dhcp snooping information option
ip dhcp snooping
no ip domain-lookup
ip domain-name xu.local
ip device tracking
ip admission name CiscoISE proxy http
!
cts sxp enable
cts sxp default source-ip 172.16.1.170
cts sxp default password 7 09747B441A54044259071C23
cts sxp connection peer 10.200.1.165 password default mode peer listener
!
dot1x system-auth-control
!
fallback profile CiscoISE
ip access-group CiscoISE in
ip admission CiscoISE
!
!
interface GigabitEthernet1/0/1
switchport access vlan 51
switchport mode access
switchport block unicast
switchport voice vlan 10
ip arp inspection limit rate 60
ip access-group ACL-DEFAULT in
authentication event fail action next-method
authentication host-mode multi-auth
authentication open
authentication order dot1x mab webauth
authentication priority dot1x mab
authentication port-control auto
authentication timer inactivity 60
authentication violation restrict
authentication fallback Dot1X
mab
snmp trap mac-notification change added
dot1x pae authenticator
dot1x timeout tx-period 60
spanning-tree portfast
spanning-tree bpduguard enable
ip dhcp snooping limit rate 60
!
!
logging origin-id ip
logging source-interface Vlan999
logging host 10.200.1.165 transport udp port 20514
!
snmp-server community cisosnmp RO
snmp-server community public RW
snmp-server enable traps snmp authentication linkdown linkup coldstart warmstart
snmp-server host 10.200.1.165 mac mac-notification snmp
snmp-server host 10.200.1.165 public
!
radius-server attribute 6 on-for-login-auth
radius-server attribute 6 support-multiple
radius-server attribute 8 include-in-access-req
radius-server host 10.200.1.165 auth-port 1812 acct-port 1813 key 7 112A484114425A3F57
radius-server vsa send accounting
radius-server vsa send authentication
!
Regards,
Arvie
Solved! Go to Solution.
04-26-2017 09:07 AM
Nino-
The client machine is not accepting the certificate from Cisco ISE since it cannot validate it. It isn't a best practice to use ISE as the certificate authority. If you have a server that is capable to run CA services, that would be a better scenario. You must have the certificate chain from the CA server (root CA) installed on the client as well as in ISE trusted certificates in order to have PKI function correctly.
HTH-
Vince
04-26-2017 09:07 AM
Nino-
The client machine is not accepting the certificate from Cisco ISE since it cannot validate it. It isn't a best practice to use ISE as the certificate authority. If you have a server that is capable to run CA services, that would be a better scenario. You must have the certificate chain from the CA server (root CA) installed on the client as well as in ISE trusted certificates in order to have PKI function correctly.
HTH-
Vince
05-08-2017 07:55 PM
Hi Vince,
Thank you for the response. Do you have any recommendations or best approach if I have this kind of setup?
Scenario:
1. AD Server
2. CA Server (not the AD server)
3. Cisco ISE Server
4. Domain PC
5. Non Domain PC
Regards,
Arvie
05-08-2017 08:21 PM
Have a look at the very good and extensive blog from Katherine
ISE - Adding Certificates to ISE and Creating Certificate Profiles
For EAP-PEAP you could also try to configure your client to ignore server certificate checking and then it won't validate the ISE server certificate. But that is just a quick and dirty workaround.
I have also written a blog article on using OpenSSL as a Certificate Authority in case you cannot get your hands on a Windows CA - you can of course also use ISE as your CA.
Rapid prototyping ISE Policies without any real networking hardware (part 3)
The answer is always 'it depends...'. But in my experience, when doing EAP-TLS you're best off using an enterprise CA such as Windows Server because it integrates well with AD, and also provides certificate revocation services (CRL/OCSP). It is also well understood in most IT Enterprises. For lab purposes you can get away with openssl.
05-08-2017 08:54 PM
Hi Arne,
Thank you.
Actually I already checked and followed Katherine's Post. I already downloaded the CA Cert from CA server to ISE as trusted certificate but from the client side what I did to make the authentication successful is I manually added the default self-signed from the system certificate of ISE to windows 7 and windows 8 clients. Is it the same certificate should I used in order for the AD to push to windows clients?
Regards,
Arvie
05-08-2017 09:35 PM
Installing the ISE self-signed certificate in clients will certainly work - but the self signed certs will expire pretty soon (I think out of the box they are valid for 1 year only). Self signed certs are mostly useful for getting you started - but you should rather consider creating an externally signed certificate for your ISE servers. You can create longer lasting certificates on external CA.
One of the immediate benefits of using your corporate CA's, is that if your clients already have your corporate CA chain in their trust store, then they will automatically trust ISE because it was signed by that CA hierarchy. No need to push the ISE self signed cert to all Windows clients.
i.e. your organisation 'MegaCorp' could have a PKI hierarchy as follows
Mega-Root-CA
Mega-Issuing-CA
You push this CA chain to all of your corporate workstations as Trusted Certificates.
On ISE you will create a certificate signing request on your PAN for 'EAP Authentication' for the PSN's that you require (use the SAN feature so that you can make one certificate for all of your PAN's - if you like). Hand the CSR to your PKI and get back the certificate which you then bind to the PSN(s).
When your windows clients perform an EAP-PEAP auth they will then honour the ISE server cert (as long as it's still valid and not revoked) because the ISE cert was signed by the Mega-Issuing-CA, which is a windows trusted CA.
07-25-2018 03:12 PM
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide