Exchange MessageTracking like a Ninja

7 września 2017 at 19:49

Dzisiaj na tapetę weźmiemy Message Tracking czyli przeszukiwanie logów poczty Microsoft Exchange dotyczących maili krążących pomiędzy serwerami pocztowymi. Niby temat znany i na pierwszy rzut oka niewiele więcej odkrywczego w nim można napisać, ale jestem przekonany że prezentowana treść może się przydać w niejednym przypadku Standardowe podejście w przypadku Message Trackingu to odpalenie w sesji Powershella z połączeniem do serwerów Exchange’a polecenia w stylu:

Ewentualnie dodanie warunków zawężających przeszukiwanie (np. data początku, data końca, Event SMTP itd.) O ile w przypadku konkretnego adresu e-mail nadawcy lub odbiorcy sprawa jest banalnie prosta bo wystarczy wykonać polecenia w stylu:

O tyle w przypadku chęci wyszukiwania wiadomości mailowych wysłanych lub odebranych z całej domeny pocztowej ‚X’ ulega znacznej komplikacji. Dlaczego? Ano dlatego, że nie ma stosownego przełącznika określającego domenę. Ba nie ma nawet stosownego filtra, więc trzeba wykorzystać coś z czego każdy świadomy Administrator korzysta w ostateczności = warunek „where” – nie tego Tygryski zdecydowanie nie lubią

W przypadku naprawdę dużych środowisk pocztowych i szerokiego zakresu wyszukiwania należy oczekiwać, że zapytanie potrwa kilka godzin jeśli nie dni a przy okazji możemy otrzymać Out-Of-Memory… A co jeśli np. potrzebujemy wykonać Message Tracking dla kilkudziesięciu różnych domen pocztowych? Kleić „like” w […]

Data Mining w skrzynce pocztowej z użyciem obiektów COM – zajawka

28 marca 2017 at 21:48

Sytuacja awaryjna – tysiące wiadomości e-mail na skrzynce pocztowej, na które trzeba odpowiedzieć w krótkim czasie jedną uniwersalną wiadomością. Niestety o autoresponderze (Out-Of-Office) lub o regule na skrzynce pocztowej nikt nie pomyślał wcześniej, o regule transportowej na Exchange’u już nie wspominając… Mamy w zasadzie 2 alternatywy: Odpowiadać na wszystkie wiadomości po kolei (albo zbiorczo) z GUI, przy czym problematyczne będzie tutaj upchanie różnych odbiorców w pole BCC (UDW) Zebrać informację o nadawcach wiadomości i wysłać zbiorczego maila dodając ich wszystkich do pola BCC. Problem jest w zasadzie tylko z „zebraniem nadawców”. Można próbować kopiować, eksportować maile, cuda wianki ale zajmuje to mnóstwo czasu a i efekt mizerny.   Podejdźmy do tego jak na administratora przystało – użyjmy Powershella 😉 Wykorzystamy do tego obiekty COM’owe Outlooka. Szybkie googlowanie da podpowiedzi w stylu:

Po wykonaniu zonk – niemiła niespodzianka:

Inne odmiany z Load Assembly również zwracają ten sam błąd… A jakie jest rozwiązanie? Jak zwykle trywialne Outlook na 99% w wersji 32-bitowej a Powershell uruchomiony standardowo w wersji 64-bitowe i tu jest zgrzyt. Wystarczy uruchomić Powershella x84 I obiekt COM’owy nie okrzyczy nas już błędami Reszta jest już prosta, łatwa i przyjemna (jeśli ktoś jest zaznajomiony z programowaniem obiektowym i […]

Wieloskładnikowe uwierzytelnianie w Powershell

20 stycznia 2017 at 10:08

Czasami/Często albo nawet i częściej niż często zachodzi konieczność przekazania komuś kompetencji w zakresie danej technologii. Gdy tylko jest to możliwe odbywa się to poprzez delegację uprawnień na poziomie aplikacji. Niestety nie zawsze jest to możliwe i zdarzają się sytuacje, w których nie można/nie da się (lub nie jest to wygodne) wydelegować uprawnień. Wtedy zazwyczaj pojawia się konieczność wydelegowania uprawnień w ramach jakiegoś konta ‚X’ i przekazania poświadczeń tego konta do grupy użytkowników celem wykonania swoich zadań. Właśnie w tym miejscu pojawia się problem jak zrobić to dobrze aby uniknąć hardcodowania haseł w treści skryptów:

Nie tędy droga – nie idźmy nigdy tą drogą błagam Hasło czystym tekstem w skrypcie to nie jest dobry pomysł. NIGDY! Natomiast próby jego „ukrywania” czy „zaciemniania” są zawsze tylko półśrodkami. Zabieg zapisania hasła w formie:

Może i utrudnia odczytanie takiego hasła wprost, ale umówmy się że nie stanowi najmniejszego problemu aby zrobić „reverse-engeneering” i wyciągnąć hasełko Kolejnym sposobem jest wykorzystanie Secure-String. Pomysł lepszy, ale nadal to szyfrowanie jest słabe i stosunkowo prosto odczytywalne:

Wystarczy wykonać:

I już znamy hasło w postaci czystego tekstu. A dodatkowo w przypadku chęci skorzystania z zapisanych poświadczeń na innej stacji odbijemy się od komunikatów o […]

Listowanie atrybutów i typów atrybutów obiektów Active Directory

25 lutego 2016 at 11:23

Dla potrzeb dokumentacji systemu pojawiła się konieczność wy-listowania wszystkich atrybutów przypisanych do danej klasy obiektów Active Directory oraz typów danych, które mogą być wprowadzane jako wartości tych atrybutów. Zadanie niby proste, ale jednak mało oczywiste… Próbując odpytać o atrybuty konkretnego użytkownika w następujący sposób:

Otrzymamy co prawda wszystkie (albo prawie wszystkie) atrybuty obiektu, jednak otrzymamy również część nieistniejących w schemacie atrybutów. Są to atrybuty interpretowane przez polecenie typu „AccountIsDisabled”, „AccountIsLockedOut” , które nie występują jako atrybuty obiektu klasy użytkownik w Active Directory, lecz wynikają z wartości atrybutu „userAccountControl”. Podejście drugie – natywny powershell do AD

I znowu kicha… tym razem mamy mniej interpretowanego przez Powershella Outputu, ale wyświetliły się tylko parametry, które mają jakąś wartość Jak więc rozwiązać ten problem? Na przykład w następujący sposób:

W ten sposób uzyskamy ładny widok wszystkich atrybutów z informacjami o ich GUID’ach o tym czy są indeksowane etc. Dane będą wyglądać mniej więcej tak: Jedyną niedogodnością jest fakt, że musimy odpytać niejako 2 razy o atrybuty dla danej klasy (raz o atrybuty obowiązkowe, raz o atrybuty opcjonalne) aby mieć komplet danych. Enjoy

Obsługa błędów w poleceniach Exchange’a

9 lutego 2016 at 11:00

Każdy posługujący się w miarę swobodnie powershell’em administrator zna sposoby wychwytywania i obsługi błędów pojawiających się podczas wykonywania skryptów. Wśród nich „króluje” często metoda „try/catch”, która w skrócie wygląda mniej więcej tak:

ww. narzędzie jest bardzo przydatne, elastyczne i pozwalające na bardzo zaawansowane rozróżnianie i obsługę poszczególnych błędów, zwłaszcza, gdy do sekcji „catch” dodamy typ błędu, który chcemy obsłużyć np:

Z czym natomiast spotyka się niemal każdy początkujący administrator próbujący budować swoje skrypty używając metody „try/catch”? Z faktem, że cześć błędów nie jest wychwytywana… Dlaczego tak się dzieje? Najczęstszymi powodami są: Niepoprawna akcja przy napotkaniu błędu (polecenia obsługujące przełącznik „-ErrorAction”, powinny mieć ustawioną akcję na „stop”) Niepoprawne preferencje obsługi błędów dla danego zakresu ($ErrorActionPreference powinno być ustawione na „stop”) A, że administrator nie lubi jak mu wyskakują błędy, to ustawia sobie ww. wartości na „SilentlyContinue” / „Continue” i w momencie, gdy dorośnie do obsługi błędów zaczyna ostre debugowanie.. Sprawa natomiast wygląda ciekawiej w przypadku poleceń Exchange’a, które są wykonywane zdalnie w ramach sesji z serwerami Exchange’a. W takim wypadku praca z powershell’em + modułami Exchange’a i nawiązanie sesji wygląda mniej więcej tak:

Dodaliśmy sobie przystawkę, nawiązaliśmy sesję, ustawiliśmy preferencje obsługi błędów i testujemy interaktywnie na konsoli obsługę […]

© Marcin Krzanowicz