Hasain Alshakarti

Yet another day of troubleshooting DirectAccess, this time it was my colleague and friend Mikael Nystrom asking about expired IPHTTPS and NLS certificates. He already knew about my other post about changing the IPHTTPS certificate.

So he did delete the old binding by using the [netsh http del sslcert] command for both external addresses, and did replace the binding by using the [netsh http add sslcert] and/or the IIS management console.

Now the DirectAccess server is restored in functional state again but Mikael realized another error, the DirectAccess Management Console started showing an error about not being able to read the XML config file due to errors in certificate hashes for the IpHttpsCertHash and NidCertHash?

Now my advice was to manually edit the %WINDIR%\DirectAccess\DirectAccessConfig.xml file and replace the certificate thumbprints in the file with the new ones from the renewed certificates. But the console was still complaining about the hashes! After some thinking and when comparing the old and the new config files we realized that the console needed the certificate hash values in CAPITAL letters!!!!

Yes, the certificate hash/thumbprint is a hex representation, and according to W3C XML Schema Part 2: Datatypes Second Edition http://www.w3.org/TR/xmlschema-2/#hexBinary:

hexBinary has a lexical representation where each binary octet is encoded as a character tuple, consisting of two hexadecimal digits ([0-9a-fA-F]) representing the octet code. For example, “0FB7” is a hex encoding for the 16-bit integer 4023 (whose binary representation is 111110110111).

Reading the above carefully, any developer can simply realize that the expression “digits ([0-9a-fA-F])” means not case sensitive, but this does apparently not apply to whom ever developed the DirectAccess Management Console in Windows Server 2008 R2

To change any of the IPHTTPS or NLS (if NLS is running on the DA server) certificate and keep the DA Management Console happy:

• Redo the certificate bindings either using the netsh http del/add sslcert command or the IIS console
• Change the IpHttpsCertHash and NidCertHash in the DirectAccessConfig.xml file and make sure the hash value is in CAPITAL letters

If you happen to know the person responsible for this at Micrososft, please give him/her the link to W3C 😉

Server side DirectAccess requires one network adapter to be configures as external with the Public or Private profile to apply the Connection Security rules. With the security connection rules in place the DirectAccess server will be able to offer IPSec authentication and tunneling to the clients.

Recently I was involved in a customer case where the DirectAccess server decided to change the external-facing interface to the domain profile, this caused the server to deactivate all security connection rules and the whole DirectAccess solution to stop working.

Now the decision about the profile type for a network interface in Windows is handled by the Network Location Awareness NLA service. The NLA probes for the possibility to reach the servers domain and if a connection is successful the profile will change to domain and the interface will be categorised as "Intranet Authenticated" according to NLA.

The solution or rather said the reason for the sudden change in the specific customer case was firewall related. The firewall was configured to allow traffic from DMZ, where the DirectAccess server external interface was connected, to the internal domain network, this caused NLA to "see" the domain over the external interface and…. So the solution was simply to configure a deny rule prohibiting the DirectAccess server external IP from accessing internal resources and all was back to normal again!

The following registry location is good help when troubleshooting NLA related problems

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\NetworkList

/Hasain

Hi,

The last Second Wednesday this year is going to be about DirectAccess. Why, who, how, when and what is it all about? Take the opportunity to discuss all of that and much mor…

Read more and reserve your free seat at:

http://www.labcenter.se/2w.aspx

or

http://www.facebook.com/event.php?eid=104672269605105&num_event_invites=0

See you the 8:th of December at LabCenter in Stockholm.

BR
Hasain

Yet another day of troubleshooting DirectAccess, this time it was about a broken IPHTTPS tunnel. During the troubleshooting we recognized that the client is not able to establish a connection the the IPHTTPS url https://da.domain.com/IPHTTPS, using a network sniffer we could very clear see the server sending a reset packet after the Client Hello message. This indicates that the SSL server is not able to continue communicating using SSL. Knowing that there was a certificate change just a few days before this error occurred we found that the old certificate was still used for the SSL binding at the DA server even though the configuration was reapplied using the DA management console after the certificate change.

When changing the certificate used for the IPHTTPS tunnel it is very important to clear the old SSL certificate binding before adding the new one.

If you configured your DirectAccess using the DA management console follow the steps below to change the IPHTTPS certificate:

·         Run the command: netsh http show sslcert
This will show the current sslcert binding with details about ip, port and the certificate

·         Delete the old bindning using the command: netsh http del sslcert

·         Using the DA management console, select the new IPHTTPS certificate, save an apply the new configuration

If you configured your DirectAccess using scripts or netsh commands to define all setting follow the steps below to change the IPHTTPS certificate:

·         Run the command: netsh http show sslcert
This will show the current sslcert binding with details about ip, port and the certificate

·         Delete the old bindning using the command: netsh http del sslcert

·         Add the new sslcert binding using the command: netsh http add sslcert

/Hasain

Det går att implementera och migrera till Windows 7, Windows Server 2008 R2 och Hyper-V R2 på massor av olika sätt, några direkt skadliga, andra helt ok med diverse för- och nackdelar och självklart vissa riktigt bra och genomtänkta.
 
Utmaningar som att samexistera med XP under en period, uppgradera roller som
AD, DNS, DHCP, Clustering, att ändra kommunikationsprotokoll och införa
nya funktioner som Direct Access m.m. kräver en hel del av oss som jobbar med IT.
 
På Summiten får du den osminkade sanningen och tipsen som du  inte finner
i manualerna om hur du inför den senaste tekniken på bästa sätt i din IT-miljö.
 
Mer information och agenda finns på http://infrastructuresummit.se/

Vi ses den 7:e oktober

/Hasain

Just some important IPv6 prefixes to remember whenever dealing with DirectAccess or IPv6 as such, have fun and remember to think in HEX J

Global-Unicast – 2000::/3
6to4 – 2002::/16
Teredo – 2001:0000::/32
Link Local Unicast — FE80::/10
Unique Local Unicast – FC00::/7
Multicast – FF00::/8

DirectAccess IPv6 addressing:
2002:WWXX:YYZZ:8000::/49 as the organizational prefix
2002:WWXX:YYZZ:8000::/64 as the ISATAP prefix
2002:WWXX:YYZZ:8001::/96 as the NAT64/DNS64 prefix
2002:WWXX:YYZZ:8100::/56 as the IP-HTTPS prefix

/Hasain

DirectAccess är mer än bara ett alternativ till VPN och för att kunna ansluta till interna resurser via Internet. DirectAccess kommer att förändra vår syn på nätverksdesign och tillsammans med IPv6 skapa oanade möjligheter till öppnare och säkrare infrastruktur oavsett var våra klienter befinner sig.

Under två dagar kommer du att förstå principen bakom DirectAccess och vilka komponenter och system den är beroende av. Du kommer även att förstå och kunna hantera de olika alternativen i båda renodlade IPv6-miljöer och blandmiljöer med båda IPv4 och IPv6 i olika grad.

Under labben kommer vi dessutom att skapa en förståelse och lägga grunden för IPv6 och skapa förståelse för kravet och hur vi kan hantera det kommande generationsskiftet i våra nät och framför allt hur samexistensen kan hanteras.

Genom att testa de olika alternativen för hur man bygger DirectAccess kommer du att kunna välja rätt strategi för just din DirectAccesss implementation till din it-miljö.

Vi  ses den 25:e oktober på LabCenter i Stockholm. Labben bokas på http://labcenter.se/Lab/2068

/Hasain