Eme darabnak az a feladata, hogy az Active Directory határain túl alakíson ki Single Sign On azonosítást.
Ez akárhogy is nézem az eddigi életemben eddig erre nem volt szükség.
Most viszont két témában is szembe jött:
Van nekünk egy Dynamics CRM-ünk. Ennek a külső web service authentikációjához (domain-en kívüli CRM kliens - Outlook) claims based authentikáció kell amit az ADFS nyújt.
Van nekünk egy Exchange-ünk. Az a döntés született, hogy költözik az o365-be, a domain viszont marad. Ezt ugyan meg lehet oldani ADFS nélkül, de ha már a CRM-hez úgy is kell akkor miért ne legyen ehhez is ADFS.
A rendszerek kritikus volta miatt rögtön kéne építeni egy ADFS farmot.
Olvastam sokat, kezdtem úgy érezni, hogy tudok eleget. Vágjunk bele a teszt telepítésbe.
Először is kell nekünk egy SQL szerver. Az ADFS defaultban ugyan WID-et használ, de én részemről hányok őnagyságától. Ráadásul itt nem is játszik, hiszen össze kell rakni egy SQL mirrort a hibatűrés miatt.
1. Tehát akkor nem telepítünk SQL-t mert ott van a CRM alatt.
2. Kell nekünk egy wildcard certificate a Default Web Site-hoz. Némi egyeztetés a főnökkel, majd gyártatok egyet a GoDaddy-vel.
3. Kell nekünk még két tanusítvány: Egy Token Signing és egy Token Encrypting.
Self-Signed cuccot nem akarok, nem is javasolják. Ha nem SS akkor milyen kell?
gugli jobbra, gugli balra. Mindenki össze vissza beszél. Végülis kiderül, hogy az egész tanúsítvány teljesen lényegtelen, csak legyen benne kulcspár.
Gyártatok kettőt a saját CA-nkkal az IIS konzolból.
Felrakom az ADFS role-t (itt már megy role alapon, mert ez egy 2012-es szerver).
Elindítom a konfig varázslót.
Az első oldalon közli, hogy ha nem WID-et akarok akkor csak parancsorból megy a móka.
Ok, gugli.
Eredmény:
A 2012-n az FSConfig a C:\Windows\ADFS könyvtárban lakik. Az általam igényelt parancsor meg ez:
FSConfig.exe CreateSQLFarm /ServiceAccount DOMAIN\User /ServiceAccountPassword password /SQLConnectionString "database=AdfsConfiguration;server=server;integrated security=SSPI" /CleanConfig /FederationServiceName FQDN /SigningCertThumbprint "Token signing certificate thumbprint" /DecryptCertThumbprint "Token decrypting certificate thumbprint"
Nem hány, tudom, hogy okádék.
Elindítom. Eredmény:
The following error occurred: The Federation Service name that was determined fr
om the Subject field of the specified certificate is not a valid DNS name. Speci
fy a certificate with a valid Subject name for the Federation Service DNS name,
and then try again.
gugli. Valahol leírják, hogy az FSConfig http-n keresztül ellenőrzi az SSL certificate-et. Ja, hogy a DNS-t meg a website-ot nem raktam össze. A dolog akkor jó, ha a böngészőben a megadott FQDN-re https-en hiba nélkül bejön az IIS kezdőoldal.
Összerakom, tesztelem. A böngészőben működik.
A parancssorban nem.
Hátha a wildcard a baja. Kérek egy teszt SSL tanúsítványt az FQDN-re.
Próba...
...nem megy.
Esetleg az FQDN-ben lévő kötőjel?
Nem
Esetleg meg kéne adni az SSL Thumbprint-jét is?
Nem.
Még néhány liba?
Nem.
A megoldás:
http://setspn.blogspot.hu/2012/04/configuring-adfs-with-custom-token.html
Remek, tehát a terv:
1. Létrehozzuk az ADFS-t SS tanúsítványokkal
2. Leállítjuk a tanúsíványok automatikus újrakérését
3. Felrakjuk a CA-tól kért tanúsítványokat
4. Kidobjuk az SS cuccokat.
Akkor a megvalósítás:
1. Létrehozzuk az ADFS-t:
FSConfig.exe CreateSQLFarm /ServiceAccount DOMAIN\User /ServiceAccountPassword password /SQLConnectionString "database=AdfsConfiguration;server=server;integrated security=SSPI" /CleanConfig /FederationServiceName FQDN /AutoCertRolloverEnabled
Lefut
2. Innen PowerShell. Leállítjuk a tanúsítványok automatikus újrakérését
Set-ADFSProperties -AutoCertificateRollover $false
Lefut
3. Felrakjuk a CA-tól kért tanúsítványokat
Add-ADFSCertificate -CertificateType Token-Signing -Thumbprint "Token signing certificate thumbprint" -IsPrimary
Lefut, de ...Közli, hogy az 1024 bites tanúsítvány nem elég biztonságos.
Ok, akkor nézzük meg. Fejest ugrok a WebServer CA Template-be. Minimum key length: 2048.
Csak épp nem veszi figyelembe.
gugli: semmi.
Ok, akkor csináljunk 2048-as template-et.
Megadom neki, hogy ez a WebServer utódja, akkor sem hajlandó használni.
gugli: Az IIS MMC-t sehogy sem lehet lebeszélni a WebServer template-ről. Arra meg én nem vagyok hajlandó, hogy fájlba mentett requestből csináljak tanusítványt. Miért? Mert nyakas vagyok.
Ok, akkor próbálozzunk a Certificate MMC-vel.
Hurrá, itt tudok gyártani megfelelő tanusítványt.
3. (másodszor) Felrakjuk a CA-tól kért tanúsítványokat
Add-ADFSCertificate -CertificateType Token-Signing -Thumbprint "Token signing certificate thumbprint" -IsPrimary
Nem fut le.Közli, hogy:
Add-ADFSCertificate : PS0025: No private key found for certificate.
At line:1 char:1
+ Add-ADFSCertificate -CertificateType Token-Signing -Thumbprint "ad 24 d1 99 a1 0 ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidArgument: (:) [Add-ADFSCertificate], ArgumentException
+ FullyQualifiedErrorId : PS0025,Microsoft.IdentityServer.PowerShell.Commands.AddCertificateCommand
Anyád.
Az IIS látja.
gugli: semmi.
Előszedem az Exchange-hez gyártott cert store-os scriptem. Kapok vissza valamit, megvan a privát kulcs, de ez a dög nem látja.
Hátha jogosultsági probléma. Az ADFS usert hozzáadom a privát kulcs olvasóihoz.
Az eredmény változatlan.
Ráolvasás, vajákolás. Semmi...
...Elkezd valami derengeni. Amikor az ADFS technetes dolgait olvastam, volt valami community megjegyzés. Mi is lehetett az???
http://technet.microsoft.com/en-us/library/dd807040%28WS.10%29.aspx
Lap alja. Ne használj 2008-as CA template-et.
Hogy az a jó büdös...
Template kuka, 2003-asal újragyárt.
Új certificate request.
3. (sokadszor) Felrakjuk a CA-tól kért tanúsítványokat
Felmegy. Hurrá
4. Kidobjuk az SS cuccokat.
PowerShell: Nem megy le.
Letojom. Leszedem az ADFS MMC-ből.
Küldetés teljesítve.
Legalábbis van egy felrakott teszt ADFS-em, megfelelő tanúsítványokkal. Hogy működik-e pl. a CRM-el, az holnap kiderül.
