www.SAMURAJ-cz.com 

15.12.2017 Radana a Radan Translate to English by Google     VÍTEJTE V MÉM SVĚTĚ

Články

Exchange Server, Outlook a certifikáty v GALu

Úterý, 27.12.2011 14:48 | Samuraj - Petr Bouška |
Článek se věnuje ukládání šifrovacích certifikátů do Active Directory. Jak k nim potom přistupují klienti jako je Outlook nebo OWA. Jaké mohou nastat problémy, když přejdeme na novou certifikační autoritu, a klientům se z AD nabízí stále staré certifikáty. A také různým PowerShell příkazům, pomocí kterých můžeme s certifikáty v AD pracovat.

Pokud používáme Microsoft Exchange server a Outlook a využíváme šifrování emailových zpráv, tak je dobré umístit šifrovací certifikáty jednotlivých uživatelů do Active Directory (AD). Potom jsou tyto certifikáty (zjednodušeně řečeno) automaticky distribuovány všem uživatelům jako součást GALu (Global Address List). Takže si uživatelé mohou navzájem posílat šifrované zprávy.

Publikování certifikátu do AD

Certifikáty se v AD ukládají do atributu u objektu uživatele. Umístit certifikát k uživateli (Publish certificate in AD) můžeme několika způsoby:

  • při vydání certifikátu - pokud využíváme MS CA, tak na šabloně můžeme nastavit, aby se certifikát automaticky publikoval do AD
  • pomocí Outlooku - uživatelé si mohou vypublikovat nastavený šifrovací certifikát sami v Outlooku (na stejném místě, kde se certifikát nastavuje pro použití), v Outlooku 2010 to je File - Options - Trust Center - Trust Center Settings - tlačítko Publish to GAL
  • pomocí ADUC - když si zobrazíme vlastnosti uživatelského účtu pomocí Active Directory Users and Computers (ADUC) a máme zapnuté zobrazení Advanced Features, tak vidíme záložku Published Certificates, zde můžeme přidávat i mazat certifikáty
  • další možnosti - pomocí nějakých příkazů jako certutil.exe, PowerShell případně i s rozšířením od firmy Quest pro AD

Problém s nabízeným certifikátem

Všechno by se zdálo jednoduché a jasné, hlavně dokud nám vše pěkně funguje. Jak už to ale u Microsoftu bývá, tak je skutečnost o dost složitější. Nedávno jsem narazil na problém, kdy jsme přešli na novou certifikační autoritu. Takže uživatelům bylo třeba vydat nové certifikáty, ty se vypublikovaly do GALu (automaticky pomocí CA). Jenže když se takovému uživateli poslal email, tak se pořád šifroval jeho starým certifikátem. Vymazal jsem tedy v AD staré certifikáty, ale to nepomohlo. Vymazal jsem všechny certifikáty, ale pořad Outlook nabízel starý certifikát. Vyzkoušel jsem všechny různé možností, které jsem popisoval v článku Šifrovaní emailů v MS Outlook a řešení problémů. Ale stále nic, až jsem nakonec situaci vyřešil, když jsem se podíval na detaily uživatelského objektu pomocí PowerShell příkazu Get-ADUser. Potom se mi podařilo dohledat i dokumentaci, kde jsem se dozvěděl, proč celá situace nastala.

Jak se certifikáty v AD ukládají

Jde o to, že certifikáty se ukládají do atributu userCertificate, to je často zmiňovaný atribut. Certifikáty jsou zde uloženy ve formátu DER Encoded X.509 v3 a tyto certifikáty se zobrazují v ADUC na záložce Published Certificates. Jenže certifikáty se také ukládají do dalšího atributu userSMIMECertificate, kde jsou pro změnu uloženy ve formátu PKCS #7 a to včetně celého řetězu certifikátů autorit.

Potom, když chceme použít certifikát v nějakém klientovi, tak záleží na klientovi, jaký atribut použije. Například MS Outlook se podívá do atributu userSMIMECertificate a pokud certifikát nenalezne, tak potom do atributu userCertificate. A aby to nebylo jednoduché, tak Outlook Web Access (OWA) to dělá přesně opačně.

Takže když smažeme staré certifikáty u uživatele pomocí ADUC, tak Outlook je bude stále používat (a ještě nastane ta zajímavá situace, že přes OWA se použije ten nový certifikát). Pokud použijeme v Oulooku funkci Publish to GAL, tak se certifikáty umístí do obou atributů. A samozřejmě se doplňují a ne přepisují. Ale pokud využijeme publikování certifikátu do AD při vystavení certifikátu, tak se uloží pouze do atributu userCertificate.

Microsoft sám uvádí ve svém článku, používejte pouze jeden z těchto dvou atributů a určitě nechcete používat userSMIMECertificate. Doporučuje také zabránit uživatelům v publikování certifikátů z Outlook (pak se totiž použije tento atribut). Trochu zvláštní tvrzení ...

Mazání certifikátů v AD

Takže v řadě praktických situací potřebujeme smazat certifikáty z atributu userSMIMECertificate. Pro ruční operaci můžeme použít ADUC (z RSAT), kde ve vlastnostech uživatele máme záložku Attribute Editor. Tam jednoduše nalezneme libovolný atribut a můžeme jeho hodnotu smazat. Pokud to potřebujeme udělat pro celou firmu, tak to není moc praktické a jako jasná volba by se stavěl PowerShell.

PowerShellu (rozšířeném o MS modul AD) můžeme použít třeba následující příkaz, který nám zobrazí informace o certifikátech. Ten ale bohužel opět pracuje jen s atributem userCertificate.

Import-Module ActiveDirectory
(Get-ADUser username -Properties Certificates).Certificates

Můžeme se ale podívat přímo na atributy.

Get-ADUser username -Properties userCertificate, userSMIMECertificate | FL Name, userCertificate, userSMIMECertificate

A obsah atributu userSMIMECertificate můžeme smazat níže uvedeným příkazem. Druhý řádek ukazuje možnost smazání pro všechny uživatele v daném kontejneru.

Set-ADUser username -Clear userSMIMECertificate
Get-ADUser -Filter * -SearchBase "OU=Firma,DC=firma,DC=local" | Set-ADUser -Clear userSMIMECertificate

Outlook 2010 - zablokování tlačítka Publish to GAL

Zrušení tlačítka Publish to GAL můžeme provést jednoduše a elegantně pomocí Group Policy. Potřebujeme k tomu, ale šablony pro Office 2010 (nebo odpovídající verzi), toto téma jsem popisoval v článku MS Outlook a konfigurace pomocí Group Policy.

Nastavení se nachází v cestě User Configuration\Administrative Templates\Microsoft Outlook 2010\Security\Cryptography pod položkou Do not display 'Publish to GAL' button.

Odstranění neplatných certifikátů z AD

Když se již bavíme o tématu certifikátů v GALu, tak určitě všichni po nějaké době narazíme na to, že nám Exchange server bude logovat varování, že se u nějakého uživatele nachází certifikát nevalidní nebo s prošlou dobou platnosti a že nebude přidán do GALu. Abychom se těmto varováním vyhnuli, tak by se hodilo automatizovaně promazávat neplatné certifikáty. Pokud to pro nás neudělá certifikační autorita, tak si musíme pomoci nějakým skriptem.

Určitě by se dal v PowerShellu s modulem pro AD napsat nějaký skript, který by využil následující informace, ale nebylo by to nic jednoduchého.

(Get-ADUser username -Properties Certificates).Certificates[0].GetExpirationDateString()
(Get-ADUser username -Properties Certificates).Certificates | foreach {New-Object System.Security.Cryptography.X509Certificates.X509Certificate2 $_} | fl * -f

Naštěstí je tu firma Quest a jejich rozšíření PowerShellu ActiveRoles Management Shell for Active Directory. Bohužel ale i jejich příkaz pracuje pouze s atributem userCertificate. Následuje několik jednoduchých příkladů, jak smazat prošlý certifikát uživatele, nevalidní, pokud je v názvu vydavatele slovo Firma nebo všechny certifikáty všech uživatelů.

Add-PSSnapin Quest.ActiveRoles.ADManagement

Get-QADUser username | Remove-QADCertificate -Expired Get-QADUser username | Remove-QADCertificate -Valid:$false Get-QADUser username | Remove-QADCertificate -IssuerDN '*Firma*' Get-QADUser | Remove-QADCertificate
zobrazeno: 9207krát | Komentáře [0]

Autor:

Související články:

Active Directory a protokol LDAP

Správa počítačové sítě ala Microsoft, to je Active Directory. Jedná se o velice rozsáhlou skupinu technologií a služeb. Základem jsou adresářové služby, adresáře a komunikační protokol LDAP.

PowerShell

Články týkající se Microsoft skriptovacího jazyku PowerShell, který se používá ve všech nových verzích MS OS a aplikací.

Pokud se Vám článek líbil, tak mne potěšíte, když uložíte odkaz na některý server:

Pokud se chcete vyjádřit k tomuto článku, využijte komentáře níže. Pokud chcete poradit s nějakým problémem či diskutovat na nějaké téma, tak použijte fórum.

Komentáře

Zatím tento záznam nikdo nekomentoval.

Přidat komentář

Vložit tag: strong em link

Vložit smajlík: :-) ;-) :-( :-O


Ochrana proti SPAMu, zdejte následující čtyři znaky image code

Nápověda:
  • maximální délka komentáře je 2000 znaků
  • HTML tagy nejsou povoleny (budou odstraněny), použít se mohou pouze speciální tagy (jsou uvedeny nad vstupním polem)
  • nový řádek (ENTER) ukončí odstavec a začne nový
  • pokud odpovídáte na jiný komentář, vložte na začátek odstavce (řádku) číslo komentáře v hranatých závorkách