• RSS
  • Twitter
  • FaceBook

Welcome to ISAserver.org

Forums | Register | Login | My Profile | Inbox | RSS RSS icon | My Subscription | My Forums | Address Book | Member List | Search | FAQ | Ticket List | Log Out

ISA, Vista and OSX L2TP\IPSec

Users viewing this topic: none

Logged in as: Guest
  Printable Version
All Forums >> [ISA 2006 Firewall] >> VPN >> ISA, Vista and OSX L2TP\IPSec Page: [1]
Login
Message << Older Topic   Newer Topic >>
ISA, Vista and OSX L2TP\IPSec - 16.Jan.2009 8:31:59 AM   
davei0594

 

Posts: 21
Joined: 9.Feb.2008
Status: offline
Hi all, bit of a long one here so bare with me....

I am struggling to get ISA 2006 STD to act as an L2TP\IPSEc VPN server using Certificate authentication for Vista and MacOSX clients.  It works fine for our
XP clients, both domain and non-domain members.

I have read about EKU and SAN fields, the required OIDs that Vista\MacOSX look for, the 'Verify the usage attributes of the server's certificate' option in
the vista vpn client (missing from XP, hence why xp works).

Vista works fine if we untick the above box - it connects fine.  Likewise it connects fine using a PSK.  MacOSX connects fine using a PSK but not cert auth. 
Again, XP just blindly sits there and works.

I understand this new feature in Vista\OSX checks the vpn server's certificate more aggressively than XP, and that it is all the name of security.  however
it is a pain in the backside as I have to allow PSK auth for the Mactards, and it has been flagged up on our latest pen test as a 'significant risk'.

i am under pressure to remove PSK auth from ISA, but also to maintain the functionality of vpn remote access for the osx and Vista clients.

We distribute a cmak profile via GPO to all windows clients.  This profile won't work on Vista (for the above reason).  I know i could reconfigure CMAK to
'take the tick out of the box' if you like, but would like to initially focus some effort on cracking the problem rather than working around it.  It's just
the kind of guy i am... (but the practicalities of life may win unless i can crack this quick!).

Set up is as follows:-

Windows Server 2003 R2 SP2 - Standard Edition everywhere
Enterprise CA (again on STD edition windows so no playing with cert templates)
CA extended to support SAN fields as per MSKB article.
Vista SP1 clients
MacOSX clients (varying versions)
CMAK profile
Single ISA 2006 STD back-end firewall terminating the l2tp\ipsec connections.
Sort of Split-DNS implementation - vpn clients connect to a host in a domain that is different from the AD domain, hence the requirement for SAN field.

The ISA is used for many things (very successfully too i must add), the result of which is that there are several certificates in the computer store on ISA. 
For the purposes of troubleshooting this i have created another ISA and vista vpn client in vmware - but member of our live domain, and using our live
enterprise CA.  Both running on an isolated vswitch so non-routable from our LAN.  The point is that my virtual ISA has fewer certificates on it - not sure
how relevant it may be in the 'black-art' that is the certificate selection process. 

These two certs are on our test ISA:-

Computer cert from enterprise ca via autoenrollment:-
CN=vmisa01.addomain.local
EKU=Client Authentication (1.3.6.1.5.5.7.3.2), and Server Authentication (1.3.6.1.5.5.7.3.1)
No SAN field.
Thumbprint:  241a13de........0e52aeb6a

Test IKE Intermediate (IPSec Offline) from enterprise ca via web enrollment:
CN=connect.externaldomain.com (this is the dns name used by vpn clients to connect)
EKU=IP security IKE intermediate (1.3.6.1.5.5.8.2.2)
SAN:dns name=connect.externaldomain.com
Thumbprint:  971274...........a11c9cc76f

The behaviour in this vmware environment is exactly the same as our live environment - i can vpn from vista to isa IF i remove the 'verify usage
attributes...' tick box.  Leaving the tick box produces the same error as live env - namely:
"Error 835:  The L2TP connection attempt failed because the security layer could not authenticate the remote computer...".

So.  Over to the ISA and the oakley ike log.  I can see the connection come in, i can see the client's cert is sent to ISA, CRL checked and then validated
and accepted.  Then when ISA assesses it's own certificates to find a match, it all starts going pete tong:-

1-16: 12:24:36:594:1a0 ClearFragList
1-16: 12:24:36:594:1a0 constructing ISAKMP Header
1-16: 12:24:36:594:1a0 constructing ID
1-16: 12:24:36:609:1a0 Find cert chain: NAP 0 ipsecusage 1
1-16: 12:24:36:609:1a0 Cert Trustes.  0 100
1-16: 12:24:36:609:1a0 Cert SHA Thumbprint 9712746d7c89efc81e4418420bdf9ea1
1-16: 12:24:36:609:1a0 1c9cc76f
1-16: 12:24:36:641:1a0 AcquireContext Sig Key error: -2146893802
1-16: 12:24:36:641:1a0 Failed to get key for cert
1-16: 12:24:36:641:1a0 Find cert chain: NAP 0 ipsecusage 1
1-16: 12:24:36:641:1a0 failed to get chain 80092004
1-16: 12:24:36:641:1a0 Find cert chain: NAP 0 ipsecusage 0
1-16: 12:24:36:641:1a0 Cert Trustes.  0 100
1-16: 12:24:36:641:1a0 Cert SHA Thumbprint 9712746d7c89efc81e4418420bdf9ea1
1-16: 12:24:36:641:1a0 1c9cc76f
1-16: 12:24:36:641:1a0 AcquireContext Sig Key error: -2146893802
1-16: 12:24:36:641:1a0 Failed to get key for cert
1-16: 12:24:36:641:1a0 Find cert chain: NAP 0 ipsecusage 0
1-16: 12:24:36:641:1a0 Cert Trustes.  0 100
1-16: 12:24:36:641:1a0 Cert SHA Thumbprint 241a13de7eef08230a4dff2a8d12170e
1-16: 12:24:36:641:1a0 522aeb6a
1-16: 12:24:36:703:1a0 Entered CRL check
1-16: 12:24:36:703:1a0 Left CRL check
1-16: 12:24:36:703:1a0 Cert SHA Thumbprint 241a13de7eef08230a4dff2a8d12170e
1-16: 12:24:36:703:1a0 522aeb6a
1-16: 12:24:36:703:1a0 SubjectName: CN=vmisa01.addomain.local
1-16: 12:24:36:703:1a0 Cert Serialnumber 720400000000ceb7b72b
1-16: 12:24:36:703:1a0 Cert SHA Thumbprint 241a13de7eef08230a4dff2a8d12170e
1-16: 12:24:36:703:1a0 522aeb6a
1-16: 12:24:36:703:1a0 SubjectName: DC=LOCAL, DC=addomain, CN=enterpriseca
1-16: 12:24:36:703:1a0 Cert Serialnumber f65d474fb40df643a5062ec8cd24fa19
1-16: 12:24:36:703:1a0
1-16: 12:24:36:703:1a0 Cert SHA Thumbprint 740246cd4e68347230f928e91c187962
1-16: 12:24:36:703:1a0 af9de113
1-16: 12:24:36:703:1a0 Not storing My cert chain in SA.
1-16: 12:24:36:703:1a0 MM ID Type 9
1-16: 12:24:36:703:1a0 MM ID 3025312330210603550403131a766d69
1-16: 12:24:36:703:1a0 736130312e6274672e6274676c6f6261
1-16: 12:24:36:703:1a0 6c2e6c6f63616c
1-16: 12:24:36:703:1a0 constructing CERT
1-16: 12:24:36:703:1a0 Construct SIG
1-16: 12:24:36:703:1a0 MM established.  SA: 0011AB98
1-16: 12:24:36:703:1a0
1-16: 12:24:36:703:1a0 Sending: SA = 0x0011AB98 to 172.16.5.1:Type 2.500
1-16: 12:24:36:703:1a0 ISAKMP Header: (V1.0), len = 1588
1-16: 12:24:36:703:1a0   I-COOKIE f07b04501efd99be
1-16: 12:24:36:703:1a0   R-COOKIE 8c832904cc1c217a
1-16: 12:24:36:703:1a0   exchange: Oakley Main Mode
1-16: 12:24:36:703:1a0   flags: 1 ( encrypted )
1-16: 12:24:36:703:1a0   next payload: ID
1-16: 12:24:36:703:1a0   message ID: 00000000
1-16: 12:24:36:703:1a0 Ports S:f401 D:f401
1-16: 12:24:36:719:1a0
1-16: 12:24:36:719:1a0 Receive: (get) SA = 0x0011ab98 from 172.16.5.1.500
1-16: 12:24:36:719:1a0 ISAKMP Header: (V1.0), len = 84
1-16: 12:24:36:719:1a0   I-COOKIE f07b04501efd99be
1-16: 12:24:36:719:1a0   R-COOKIE 8c832904cc1c217a
1-16: 12:24:36:719:1a0   exchange: ISAKMP Informational Exchange
1-16: 12:24:36:719:1a0   flags: 1 ( encrypted )
1-16: 12:24:36:719:1a0   next payload: HASH
1-16: 12:24:36:719:1a0   message ID: 4a37c584
1-16: 12:24:36:719:1a0 processing HASH (Notify/Delete)
1-16: 12:24:36:719:1a0 processing payload NOTIFY
1-16: 12:24:36:719:1a0 notify: AUTHENTICATION-FAILED
1-16: 12:24:36:719:1a0 isadb_set_status sa:0011AB98 centry:00000000 status 35e9

A couple of things confuse me here (which is not hard i know):-

1.  The error "AcquireContext Sig Key error:  -2146893802".  This error only appears during assessment of the IKE certificate (thumbprint starting 9712) and
NOT the machine certificate acquired through autoenrollment.  I cannot find anything of any use from Google, but the nature of the error suggests to my small
brain that there is a problem with retrieving the private key of the certificate? or something along those lines.  However in the certificates snapin,
looking at the properties of the certificate, it clearly states "You have a private key that corresponds to this certificate", and under certification path
the cert chains up to our enterprise CA and is marked "This certificate is OK".

2.  "MM established" at the bottom, with an SA, but then ISA sends the 'AUTHENTICATION-FAILED' message to the client.  How can Main Mode be established and an SA exist?

So the process this appears to go through is:-

Isa authenticates the client certificate (not part of the paste above)
Isa enumerates it's own certificates and rolls through them looking for a suitable match
Isa finds the IPSec cert, and KNOWS that it is valid for IPsec (by the ipsecusage=1 attr listed in oakley log above)
ISA discounts the IPSec cert for some reason (acquirecontext sig key error?)
ISA moves onto the 'generic' machine cert.
ISA sees that this machine cert does NOT support IPSEc usage (by the NAP 0 IPsecusage 0) line in oakley log, above the machine cert thumb starting 241a1),
but then appears to select this certificate for the server side of the IKE negotiation.  Why?, when it clearly says 'ipsecusage-0'?
ISA decides this machine cert is good to be used for this purpose, so enters CRL check which comes back OK.
ISA then uses this certificate to authenticate the vista client, but fails and sends the 'AUTHENTICATION FAILED' isakmp message.  I think this failure occurs
due to the lack of SAN:dns entry on the machine certificate, because the client connects to a dns name OTHER than the CN on the machine certificate.  Which
does make sense to me, hence the requirement for SAN field.

So.  I can see roughly what it's doing, i know roughly what i want it to do.  What i want to get more visibility into is why ISA discounts the IKE
certificate (with the necessary SAN and EKU fields), and chooses the machine cert that has neither the correct EKU nor SAN fields.

If anybody can help me shed some light on this i would be very grateful.  I can post the full oakely.log if it helps, and answer any req for info i have not provided.

Many thanks.

davei

Post #: 1
RE: ISA, Vista and OSX L2TP\IPSec - 16.Jan.2009 9:53:57 AM   
adimcev

 

Posts: 380
Joined: 19.Oct.2008
Status: offline
Please note that the "notify: AUTHENTICATION-FAILED" message is received by ISA from your Vista machine: "1-16: 12:24:36:719:1a0 Receive: (get) SA = 0x0011ab98 from 172.16.5.1.500".

You need for Vista a certificate on ISA that contains the Server authentication(1.3.6.1.5.5.7.3.1) EKU, if you want to use the Verify the Name and Usage attributes of the server's certificate checkbox. Please read this.

What you described above, I've already explained here. (not with Vista, but with Mac OS X, anyway is pretty much the same thing).

The problem is that, since you need to support both Vista and Mac OS X L2TP/IPsec VPN clients, you have a situation:

- it appears the VPN server's certificate checks on Macs are hard-coded or so(I don't know how to disable them), and that you need a certificate on ISA with the SAN corresponding to the FQDN of the VPN server to which the Mac OS X VPN client connects and also this certificate must incorporate no EKU fields or the ikeIntermediate (1.3.6.1.5.5.8.2.2) EKU.

- with Vista, if you want to use the Verify the Name and Usage attributes of the server's certificate checkbox., you need a certificate on ISA with the CN(or SAN)corresponding to the FQDN of the VPN server to which the Vista VPN client connects and also this certificate must incorporate the Server authentication(1.3.6.1.5.5.7.3.1) EKU field.

So the EKU fields are the issue here from the clients perspective. I did not try to issue a certificate containing the both Server authentication and  ikeIntermediate EKUs, with the appropriate SAN entry, to see if this certificate is accepted by both VPN clients.

The other issue is on the VPN server, as it appears that the Windows API is unable to be manually configured to select what certificate to be used for IKE authentication. So, this would imply, in case of ISA, when due to SSL bridging web publishing rules or so multiple certificates may exist on ISA, it's hard to know which certificate will be used by the Windows API for IKE authentication of the L2TP/IPsec VPN clients, that is, you don't know which FQDN to configure as the VPN server's address on you VPN clients performing certificates checks.

What you see, is a poor implementation of good/recommended security from both Windows and Mac OS X.

If they would want to perform such checks during IKE authentication to avoid MITM, they should have given the flexibility to configure which checks over which fields from the VPN server's certificate the VPN clients performe.
And, on the Windows server, we should be able at least to select which certificate uses the VPN server for IKE authentication.
What is really annoying, is that both Mac OS X and Vista check the EKU fields too, which may add exactly 0 security, as the VPN clients' certificates may contain no EKU, or contain too the ikeIntermediate or Server Authentication EKUs(for example if you use the autoenrollment for Windows domain member machines, you will get a machine certificate witht the Computer Template or so, containing the Server Authentication EKU). And, with IKE, unlike in case of TLS, it is not commonly known or so that the server's certificate contains the Server Authentication EKU and the client's certificate contains the Client Authentication EKU, so that everybody to follow these rules. Due to that, we have a jam here.

So if you have multiple certificates on ISA, and want to support both Vista and Mac OS X L2TP/IPsec clients, you may:
- disable the check Verify the Name and Usage attributes of the server's on Vista, and use your Windows Enterprise CA for issuing certificates for IKE authentication.
- create a separate PKI(a different CA) for Mac OS X L2TP/IPsec VPN clients, maybe like this.

For IKE authentication, by default, due to the Windows default L2TP IPsec policy, the VPN server will request certificates from the VPN clients from both CAs(as it was configured with certificates from both CAs, certificates that can be used for IKE authentication), and the VPN clients will select the appropiate certificate from their store, which will make the VPN server to use a certificate from the same CA too.

Adrian

< Message edited by adimcev -- 16.Jan.2009 10:03:02 AM >


_____________________________

Blog: http://www.carbonwind.net/blog

Get Our ISA 2006 Book!: http://tinyurl.com/2gpoo8

(in reply to davei0594)
Post #: 2
RE: ISA, Vista and OSX L2TP\IPSec - 16.Jan.2009 10:44:40 AM   
davei0594

 

Posts: 21
Joined: 9.Feb.2008
Status: offline
Adrian,

Many thanks.  I have previously read with great interest most of those articles from carbonwind that you referenced (which are brilliant), but clearly I have misunderstood something somewhere.

I will have a good read through your post this afternoon as work allows, and compare with our ISA(s) and come back to you if that is OK.  Something you said doesn't quit marry up with something i'm seeing, but i can't quite put my finger on it yet.  will investigate more and come back and post asap.

thanks again.

dave

(in reply to adimcev)
Post #: 3

Page:   [1] << Older Topic    Newer Topic >>
All Forums >> [ISA 2006 Firewall] >> VPN >> ISA, Vista and OSX L2TP\IPSec Page: [1]
Jump to:

New Messages No New Messages
Hot Topic w/ New Messages Hot Topic w/o New Messages
Locked w/ New Messages Locked w/o New Messages
 Post New Thread
 Reply to Message
 Post New Poll
 Submit Vote
 Delete My Own Post
 Delete My Own Thread
 Rate Posts