Author: SUF

Tegnapelőtt este egy weboldal nem engedett be. Megpróbáltam resetelni a jelszavam. A folyamat:

Küldenek egy e-mail-t, amiben van egy link, erre kattintva kapok egy másik levelet, benne az egyszerhasználatos jelszavammal. Szokásos eljárás.

Megjött az első levél, rákattintok a linkre, közli, hogy küldi a jelszavam.

Második e-mail sehol. Várok… várok… még mindig várok. Nem jön.

A dolog nem volt se fontos, se sürgős, így napirendre tértem a téma felett.

Másnap reggel a telefonomon nézem az adott postaládát, a levél ott van. A megfelelő időben, előző este érkezett.

Leültem az irodai gépem Outlookja elé. A levelet ott sem látom. Akkor nézzük meg OWA-ban. Bejelentkezek a saját nevemben, majd megpróbálok átlépni abba a postaládába, ahova a levél érkezett (ez nem az elsődleges fiókom, hanem a freemail fiókom “exchange-esített” változata). Nem sikerül, az OWA dob egy ronda hibát valami null property-re.

Keresgélek a neten és ezt találom:

http://support.microsoft.com/kb/2777852

Remek, ezek szerint akkor tudom megnyitni a másik mailboxom ilyen módon az OWA-ban, ha a freemail.hu-t felveszem az accepted domain listára. Ehhez valahogy nincs kedvem.

Belépek a postaládába az eredeti felhasználója nevében.

A keresett levél ott van… és … azt állítja magáról, hogy private. Ok. Ez teljesen érthető. A private jelzéssel rendelkező leveleket a Full Access joggal rendelkező másik felhasználó nem láthatja.

Ez így nekem nem jó.

Tehát a megoldás:

– csinálok egy terjesztési csoportot

– belerakom az összes érintett másodlagos postaládát

– csinálok egy Transport Rule-t amely az összes a terjesztési csoport tagjainak menő levélről leszedi a Sensitivity fejlécet, ha abban private/personal/confidental van.

Teszt kívülről. Működik.

Ne is keressük a címben szereplő EMS cmdletet. Nincs ilyen. A párja az Enable-ExchangeCertificate természetesen létezik. Van még olyan, hogy Remove-ExchangeCertificate, de az nem ugyanaz.

Miről is van szó?

Egy kissé is tapasztalt Exchange rendszergazda tudja, hogy az Enable-ExchangeCertificate parancsal lehet, a certificate store-ban tárolt tanúsítványokat az Exchange különböző szolgáltatásaihoz rendelni.

Néhány héttel ezelőtt az egyik ügyfelünknél azt a feladatot kaptam, hogy rakjam rendbe a tanúsítványokat. Ez abból állt volna, hogy a régi, már nem használt tanúsítványokat leszedjük a szolgáltatásokról, majd a tesztidőszakot követően eltávolítjuk a store-ból.

Először elkezdtem keresni, hogy milyen parancsal lehet ezt megtenni. Sokat keresgéltem, de csak azt találtam, hogy a tanúsítványt el tudom távolítani a store-ból, de a szolgáltatást nem tudom leszedni róla.

Az ügyfélnél ez egy alacsony prioritású feladat volt, így  a dolgot végül is ennyiben hagytuk.

Tegnap a nagy álljunk vissza androidra című felbuzdulásom kapcsán nekiálltam, hogy rendbetegyem a saját Exchange-emen az IMAP tanúsítványát. A problémáról itt írtam: http://it-pro-hu.blogspot.hu/2013/02/mi-bajom-az-androiddal.html A feladat a következő:

Az IMAP-nak a már jó ideje megvett, de be nem üzemelt Netlockos tanúsítványt kell használnia, az IISnek ugyanakkor a saját CA által kiállítottat mert nem akartam most szétszedni az egyész SAN-os/Autodiscover-es miskulanciát.

Megpróbáltam az IMAP-ról leszedni a régi tanúsítványt és természetesen újra a néhány héttel ezelőtti problémába futottam. Itt és most viszont nem akartam feladni. Arra gondoltam, hogy az Exchange azt az információt, hogy melyik tanúsítvány van hozzárendelve egy adott szolgáltatáshoz, biztosan tárolja valahol. Az Exchange tudtommal a különböző konfigurációs beállításokat alapvetően két helyen tárolja: az Active Directory-ban és különböző XML konfigurációs fájlokban:

– ADSIEdit -> configuration namespace -> semmi

– LDIFDE -> configuration namespace export -> az export fájlban keresgélve -> semmi

– Előkerestem az IMAP és POP3 szolgáltatás .Net Assembly-jét -> .config fájl -> semmi

– IIS Metabase -> semmi

Kezd a dolog kifogni rajtam. Felhívtam Józsit, hátha van valami ötlete. Sajnos nem volt.

Tovább keresgélve ráakadtam erre a cikkre:

http://www.msexchange.org/articles-tutorials/exchange-server-2007/management-administration/managing-exchange-certificates-part3.html

Itt ezen megakadt a szemem:

By running the cmdlet, Enable-ExchangeCertificate, you will enable a certificate for one or more services by updating the metadata stored with the certificate.

Every service has different metadata requirements, and will have different properties updated:

• POP3-IMAP4: msExchPopImapX509CertificateName property will be updated;
• IIS: Default Web Site will be updated;
• SMTP: the Network Service account will be granted Read access to the appropriate private file key in the directory Documents and Settings\All Users\Application Data\Microsoft\Crypto\RSA\MachineKeys;
• UM: certificate property will be updated to include Unified Messaging.

Hoppá, ezek szerint nem reszelgetünk konfigurációs információkat, hanem a névegyezőségből és a tanúsítvány jogokból adódik, hogy mi látszik a Get-ExchangeCertificate parancs kimenetében.

Ellenőrzésképpen tettem is egy gyors próbát.

Az alapállapot az volt, hogy mind a saját CA-m által kiállított tanúsítvány, mind a NetLock-os hozzá volt rendelve az IMAP szolgáltatáshoz.

Az IMAP szolgáltatáson elrontottam a site nevét.

Láss csodát: Mindkét tanúsítványról eltűnt az IMAP flag. Ezek után persze kérdés, hogy a rendszer mi alapján dönt, ha több lehetséges tanúsítvány van.

A másik része a dolognak az All Users\Application Data\Microsoft\Crypto\RSA\MachineKeys könyvtár tartalma. Itt találhatóak a Local System tanúsítványai. Sajnos a fájlnevek köszönő viszonyban sincsenek a tanúsitvány thumbprintjével, firendly nevével, vagy CN-jével, vagy akár bármi értelmezhető paraméterével. Az itt található tanúsítványok közül az használható SMTP hitelesítésre amilyikre a Network Service usernek olvasási joga van (az az érzésem, hogy ez az olvasási jog ugyanúgy szükséges a POP3-hoz és az IMAP-hoz is de ezt még nem tudtam tesztelni, ha ez igaz és szükséges a tanúsítványok szétválasztása, akkor érdemes elgondolkozni, hogy a Network Service helyett egyedi service accountokat használjuk a szolgáltatásokhoz).

Ha itt állítani akarunk valamit akkor merül fel a kérdés, hogy a fájlok közül vajon melyiket kell piszkálnunk, amikor mi csak a tanúsítvány thumbprintjét ismerjük (jó lenne ezeket a jogokat a certificate mmc-ben állítani, de ott sajnos erre nincs lehetőség).

Vajon hogyan tudjuk a thumbprintet összerendelni a fájlokkal? Újabb keresgélés a neten. A megoldás innen adódik:

http://jorgequestforknowledge.wordpress.com/2012/02/10/managing-certificates-on-a-windows-computer-with-powershell/

Az itt található scripteket kicsit átpofozva írtam egy scriptet ami a thumbprint alapján megadja a fájl nevét és a jogosultságait:

param([string]$ThumbPrint)
$Cert = dir cert:\LocalMachine\My | where {$_.ThumbPrint -eq $ThumbPrint}
$MachineKeysLocation = $env:ALLUSERSPROFILE + “\Microsoft\Crypto\RSA\MachineKeys\”
$KeyFileName = $Cert.PrivateKey.CspKeyContainerInfo.UniqueKeyContainerName
$KeyFilePath = $MachineKeysLocation + $KeyFileName
Write-Host FriendlyName: $Cert.FriendlyName
Write-Host Subject: $Cert.Subject
Get-Acl $KeyFilePath | fl