Forefront UAG – DirectAccess Part 9

Når man skal debugge eller logge DirectAcces traffik (6to4 – Teredo – IP-HTTPS), kan man med fordel gøre det indefra TMG (Threat Management Gateway).
Start her “Forefront TMG Management” og vælg “Logs & Reports”.

Under “Logging”, vælg “Edit Filter” og tilføj “Protocol” og “Source Network”. Konfigurer, som vist på nedenstående billede.

 

Klik på “Start Query”.


Man kan her se logs for DirectAccess transition traffik. Nedenstående Log-udsnit vises for 6to4.

 

Log udsnit for Teredo.

Log udsnit for IP-HTTPS.

For at få remote adgang til DirectAccess klienterne i forbindelse med support og helpdesk kald, kan man benytte følgende værktøjer.

– Remote Assistance i Windows 7
– Remote Desktop i Windows 7
– Teamviewer

For Remote Assistance i Windows 7, kan man lave en genvej ude på skrivebordet med følgende streng.
%windir%system32msra.exe /offerra

For at kunne lave en “Remote Assistance ” ude på klienterne, skal man forinden tillade det i en GPO (WIN_DA_Client).
Computer Configuration/Administrative Templates/System/Remote Assistance

Nedenstående billeder viser “Remote Assistance” anmodninger ude på en DirectAccess klient.


For at kunne lave en “Remote Desktop” ude på klienterne, skal man forinden tillade det i en GPO (WIN_DA_Client).
Computer Configuration/Administrative Templates/Windows Components/Remote Desktop Services/Remote Desktop Session Host/Connections
Enable “Allow users to connect remotely using Remote Desktop Services”.

 

Man kan også vælge at benytte Teamviewer, som jeg personligt syntes er en rigtig god løsning.
http://www.teamviewer.com/da/

Da jeg skulle teste DirectAccess med en Windows 7 klient, kunne jeg ikke få “Teredo” til at virke.
Min test klient var på en anden lokation i et netværk med Active Directory.
Efter en del fejlsøgning, fandt jeg nedenstående link, som beskriver problemet.
http://technet.microsoft.com/en-us/library/ee844125(WS.10).aspx

If the Teredo state is offline and the error state is Client is in a managed network, the DirectAccess client has detected a local Active Directory domain. In this case, the Teredo client will not bring up the Teredo tunnel adapter unless the Teredo client has been configured as an enterprise client. You can view the Teredo client type from the netsh interface teredo show state command. If set to client, a reachable domain controller will prevent Teredo from becoming active. If it set to enterpriseclient, Teredo will be active even when a domain controller is reachable. You can change a Teredo client from client to enterpriseclient with the Computer ConfigurationPoliciesAdministrative TemplatesNetworkTCPIP SettingsIPv6 Transition TechnologiesTeredo State setting of the Group Policy object for DirectAccess clients or for an individual DirectAccess client with the netsh interface teredo set state enterpriseclient command.

Efter jeg satte “Teredo state” til “Enterprise Client”, virkede det uden problemer. Jeg brugte igen GPO’en WIN_DA_Client.

 

Et andet problem, som jeg også brugte en del tid på at fejlfinde, var at få IP-HTTPS til at virke for mine test klienter.
Nedenstående billede viser fejlmeddelsen ude på en DirectAccess klient.

Jeg havde købt et GoDaddy standard SSL certifikat og havde importeret det til UAG serveren inden installationen af UAG.
Så jeg vidste at “Certificate Revocation List (CRL)” var i orden og det således burde virke.
Jeg kørte først kommandoerne net stop iphlpsvc og net start iphlpsvc på selve UAG serveren og klienterne uden nogen possetiv effekt.
Jeg tjekkede flere gange GPO resultet på klienten med nedensående kommado og alt så fint ud.
gpresult /f /h c:report.html

Kommandoen netsh interface httpstunnel show interface på UAG serveren viste heller ingen fejl.

Kommandoen netsh http show sslcert på UAG serveren viste heller ingen tydlige fejl.

 

Jeg havde dog forinden lagt mærke til at UAG installationen smider et “Default Web Site” SSL certifikat ind i personal certifkat storen.
Dette er et internt/privat certifkat hvor CRL ikke er public.

Ved at sammenligne “Certificate Hash” og Thumbprint fra “Default Web Site”, kunne jeg se, at UAG serveren fejlagtigt havde brugt dette certifikat under “SSL Certificate bindings”.
Det betyder at DirectAccess klienterne ikke kan lave et CRL check på certifikatet og således vil fejle.

 

Opgaven bestod nu i, at ændre bindings tilbage til mit GoDaddy SSL certifikat.
Jeg kopierede først “Application ID” for IP:port 0.0.0.0:443 og [::]:443 og satte det ind i et tekstfil.
Herefter slettede jeg de eksisterende IPports, som vist på dette billede.

Næste step, var at kopiere “Certificate Hash” fra mit GoDaddy certifkat ind i nedenstående kommandoer.
Samtidig skulle jeg også indsætte de før kopierede” Application ID’s” så de passede med de rigtige IPport.
netsh http add sslcert ipport=0.0.0.0:443 certhash=14bae9c801da96021b5d0a502e49dde47228b18a appid={4dc3e181-e14b-4a21-b022-59fc669b0914} certstorename=MY dsmapperusage=enable
netsh http add sslcert ipport=[::]:443 certhash=14bae9c801da96021b5d0a502e49dde47228b18a appid={1d40ebc7-1983-4ac5-82aa-1e17a7ae9a0e} certstorename=MY dsmapperusage=enable

Nedenstående billede viser at kommandoerne blev kørt igennem og “SSL certificate bindings” nu er ændret til mit GoDaddy SSL certifikat.

For at teste/force IP-HTTPS ude på en klient kørte jeg nedenstående kommandoer, som disabler “6to4” og “Teredo”.
netsh interface teredo set state disabled
netsh interface 6TO4 set state disabled

Jeg kørte til sidst kommandoen netsh interface httpstunnel show interface igen og kunne se, at der nu var hul igennem. Case closed….

Denne blog-post serie omkring UAG og DirectAccess er nu afsluttet.

Comments are closed.