Cisco zase předvedlo, že to občas plácají bez ladu a skladu, prostě co koho napadne, tak to tam přidají. Ve stylu "teď mě volal zákazník, že potřebuje blokovat všechny TCP pakety, které mají v sedmnáctém bajtu hodnotu dvacet tři". "Hmmm, to je fakt, to potřebuje každej, to bude zřejmě nějaká bezpečnostní díra, když to ten zákazník požaduje, tak mu tam na to přidejte zaškrtávátko". "Ale kdyžtak to radši na webu moc nevysvětlujte, ať nějakej šťoural zbytečně nezjišťuje, na co to je, když to ani sami nevíme". "Jo a ještě na to udělejte nějakej hodně dlouhej CLI komand, navrhuju - apply tcp inspect byte17 overwrite silent brutaldrop remap policy."
Dneska tu máme inteligentně vyřešené Active Directory mapování certifikátů. Dokumentace k ISE nám říká toto:
Certificate Retrieval for EAP-TLS Authentication
ISE supports certificate retrieval for user or machine authentication that uses the EAP-TLS protocol. The user or machine record on Active Directory includes a certificate attribute of the binary data type. This certificate attribute can contain one or more certificates. ISE identifies this attribute as userCertificate and does not allow you to configure any other name for this attribute. ISE retrieves this certificate and uses it to verify the identity of the user or machine. The certificate authentication profile determines the field to be used for retrieving the certificates. For example, Subject Alternative Name (SAN), Common Name, or Social Security Number (SSN). After ISE retrieves the certificate, it performs a binary comparison of this certificate with the client certificate. When multiple certificates are received, ISE compares the certificates to check for one that matches. When a match is found, ISE grants the user or machine access to the network.
Co to je? Máte 802.1x a ověřujete počítače, nebo uživatele, pomocí certifikátů a protokolu EAP-TLS. To znamená, že člověk/počítač ukáže certifikát (veřejná část) a podepíše svým privátním klíčem nějaký paket, aby se ověřilo, že ten privátní klíč opravdu vlastní. ISE ověří platnost certifikátu a celého jeho stromu a zkontroluje i CRL. To je ještě normálka (krom toho, že rozjet kontrolu toho CRL je pěkné peklo :-).
Jenže potom chce najít v LDAPu Active Directory účet, ke kterému ten certifikát patří. Na to pánové zvolili nejblbější možnou metodu - tzn. prohledají celé ADčko a snaží se tam najít ten certifikát v komplet binární formě. Certifikáty mají cca 1500 B. Navíc to hledají natvrdo jen v atributu userCertificate, což nejde změnit. Představte si, když máte tisíce účtů. Navíc v tom atributu userCertificate máte normálně další certifikáty emailové a EFS, které si Outlook stahuje do offline address book (OAB).
Kdo tohle má proboha spravovat? Proč bych importoval tolik certifikátů do AD jen kvůli mapování účtů? Potom bych je měl zase mazat, až vyprší (expire), nebo je někde zneplatní (revoke). Tohle se přece dělá jinak. Normálně by stačilo, kdyby se podívali do toho certifikátu a podle nějaké jeho hodnoty, například Subject, nebo Subject Alternative Name (SAN), nebo Thumbprint se snažili hledat hodnotu nějakého volitelného atributu v AD.
Tak se to dělá normálně při přihlašování čipovou kartou (smart card logon, Kerberos PKINIT). Nápad, že by se při přihlašování čipovkama musely ty certifikáty importovat do LDAPu, se Microsoft neodvážil mít ani ve snu. Prostě se při nejhorším vypne SAN mapování a udělá se místo toho mapování (altSecurityIdentities) právě podle těch jiných částí certifikátu.
Co nás čeká příště? Počítám, že Cisco vymyslí ověřování podle ksichtu. Vyfotí si vás a pak budou hledat fotku v ADčku :-)