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.
semmi se szereti a ws08-as cert sablonokat, és a TMG-vel sz0ptam egy jó nagyot anno :)
VálaszTörlésÉn úgy találkoztam az ADFS-sel, hogy volt egy ügyfelünk, akinél beragadt néhány óra év végén és úgy döntöttek, arra használják el, hogy tervezzek nekik ADFS-t. Fogalmuk sem volt róla, hogy mi az, abszolút nem is volt rá szükségük, de jól hangzott a neve és kiváncsiak voltak. Kénytelen voltam átrágni magam a témán, aztán szerencsére némi fejtágítás után sikerült őket lebeszélni róla.
VálaszTörlésHát nekem nem opcionális a dolog. Már eleve van egy működő ADFS-ünk a CRM-hez. Ennek költöznie kell. Ha már hozzányúlok, megcsinálom rendesen. :-)
TörlésHamár o365, lehet érdemesebb volna crm online-t használni, akkor elég a dirsync pass sync-el és nem kell legalább 4 szerver csak az ADFS miatt.
VálaszTörlésAz, hogy a CRM marad és nem megy az O365-be az eldöntettett. Egy összehasonlításra viszont kiváncsi lennék dirsync kontra ADFS. Egyébként a 4 szervert nem értem. Van két DC-m, rákerül két SQL + két ADFS. Eléjük egy Amazon ELB. Ez számomra 0 db plusz szerver, vagy kimaradt valami?
TörlésDirsync már tud jelszót szinkronizálni, most már csak speciális igények esetén érdemes ADFS-t bevezetni.
VálaszTörlés"Because ADFS requires the installation of Internet Information Services (IIS), we strongly recommend that you not install any ADFS components on a domain controller in a production environment.
http://technet.microsoft.com/en-us/library/cc778681(WS.10).aspx
Nyilván ha tudsz másik redundáns reverse proxy-t használni akkor nem kell 2 plusz szerver. Csak fizetni kell érte :)
CRM Online egy külön szolgáltatás, nem az O365 része. O365-ből is meg lehet venni és tudja használni akár az Azure AD-t, de ettől még nem része.
Az ADFS-el az a baj, hogy hibatűrőre KELL megcsinálni. Ha nem működik, nem lehet bejelentkezni. Ha van egy georedundáns nagy rendelkezésre állású rendszered o365-ben, akkor annak a rendelkezésre állását nagy mértékben lehet csökkenteni egy helyi adfs-el. Hiába van pl. 2 helyi DC-d ha csak egy internetkapcsolatod van és mindkettő egy telephelyen van közös áramellátással. Hibatűrőre kell megcsinálni, úgy hogy a reverse proxy-k egy címen tudják elérni az ADFS-t.
VálaszTörlésRáadásul, ha nem ADFS proxy-t használsz, hanem külsőt még a biztonsági szintet is lejjebb kell venni.
Arról nem is beszélve ha nem megy az ADFS akkor senki nem tud gyakorlatilag semmit csinálni és egy komplex rendszert kell tudni tanúsítványostul, különböző kliensek különböző hozzáférésein keresztül és mindenestük. Akár hétvégén, éjszaka, még akkor is amikor szabin vagy vagy beteg.
Míg ADFS nélkül annyi a feladat, hogy felhívja valaki a supportot.
Javítás:
VálaszTörlésArról nem is beszélve ha nem megy az ADFS akkor senki nem tud gyakorlatilag semmit csinálni és egy komplex rendszert kell tudni debuggolni tanúsítványostul, különböző kliensek különböző hozzáférésein keresztül és mindenestül. Akár hétvégén, éjszaka, még akkor is amikor szabin vagy vagy beteg.