Protokół NTLM służy do uwierzytelnienia (authentication), czyli jego celem jest sprawdzenie kto chce wykonać daną czynność (np. zalogować się do komputera lub zdalnie uruchomić proces na komputerze). Jeśli dwa komputery (klient i serwer) znajdowałyby się w  domenie AD, a połączenie wykonywano by z wykorzystaniem nazwy komputera to zostałby wykorzystany protokół Kerberos. Jeśli jednak komputery znajdują się w grupie roboczej lub do połączenia wykorzystano adres IP to Windows użyje protokołu NTLM.

Jak wiadomo najbardziej wrażliwą informacją o użytkowniku jest jego hasło i dlatego nikt nie chce przesyłać hasła po sieci. NTLM stosuje więc pewną sztuczkę. Komputer kliencki generuje pewną frazę i szyfruje ją z wykorzystaniem hasła użytkownika. Jest to wyzwanie dla komputera serwera, który musi teraz sprawdzić czy hasło jest poprawne. Skąd się wzięło hasło na komputerze kliencie? To proste – podał je użytkownik! A skąd komputer serwer weźmie poprawne hasło? Zazwyczaj komputer serwer nie zna tego hasła, ale może poprosić o pomoc kontroler domeny. Kontroler jest w stanie dla komputera serwera dokonać przeliczeń na haśle i w ten sposób kontroler domeny pomaga w wygenerowaniu klucza sesyjnego, jakim dalej mogą się posługiwać komputery klient i serwer.

NTLM często bywa wyłączony, bo Kerberos jest bezpieczniejszy! W przypadku Kerberos weryfikowany jest nie tylko klient przed serwerem ale jeszcze dodatkowo serwer przed klientem. W NTML wcale nie ma pewności, że serwer z którym klient się chce połączyć jest rzeczywiście tym do którego się chciało połączyć. NTLM nie chroni administratora przed atakiem man-in-the-mddle.

Zdarza się, że programista aplikacji z jakiej ma również skorzystać skrypt powershell przewidział wyłacznie interfejs wymiany danych w postaci web service. Zobacz, jak łatwo można korzystać z web service z poziomu Powershell.

Tutaj skorzystamy z publicznie dostępnych web service http://www.webservicex.net

Po pierwsze należy utworzyć obiekt WebServiceProxy, który zostanie zainicjowany adresem web service. W tym przypadku sięgamy po webservice podający dane na temat lotnisk:

$a = New-WebServiceProxy ‚http://www.webservicex.net/airport.asmx?WSDL’

Teraz w dokumentacji web service należałoby zobaczyć, jakie metody można wywoływać dla utworzonego web service proxy. Tutaj skorzystaliśmy z GetAirportInformationByCountry:

$a.GetAirportInformationByCountry(‚Poland’)

Informacja zwrócona przez web service to oczywiście XML, jednak powershell domyślnie zaprezentuje go w postaci zwykłego tekstu. Aby jednak zobaczyć XML należy zrzutować ten tekst na [xml]. Tak utworzony XML ma element główny o nazwie NewDataSet a w nim element o nazwie Table. Korzystając więc z metody web service getAirportInformationByAirportCode można w czytelny sposób wyświetlić informacje o lotnisku w Poznaniu lub Katowicach:

(([xml]$a.getAirportInformationByAirportCode(‚POZ’)).NewDataSet).Table
(([xml]$a.getAirportInformationByAirportCode(‚KTW’)).NewDataSet).Table

Członkowie ODS PTI (Oddział Dolnośląski Polskiego Towarzystwa Informatycznego) mogą uzyskać darmowy dostęp do szkoleń!

• PowerShell dla administratora Windows – szkolenie, na którym możesz nauczyć się tworzyć skrypty z wykorzystaniem języka skryptowego PowerShell. W skład szkolenia wchodzi ponad 6 godzin nagrań video oraz quizy i zadania do samodzielnego rozwiązania
• SQL Server – wprowadzenie. Instalacja i narzędzia – szkolenie wprowadzające w tematykę SQL, prezentuje podstawy pracy z bazą danych MS SQL 2016 oraz pokazuje, jak zainstalować SQL Server i jak korzystać z podstawowych narzędzi administratora baz danych. Szkolenie jest dedykowane dla osób nie znających SQL. Około 2,5 godziny materiału video
• SQL Server – zapytania. Querying – szkolenie, które na przykładzie MS SQL Server uczy samodzielnego pisania zapytań SQL. Lekcje rozpoczynają się od przedstawienia najbardziej podstawowego polecenia SELECT, poprzez zaprezentowanie typów i funkcji SQL, a kończą się omówieniem JOIN, podzapytań i operacji na zbiorach danych. Około 5 godzin materiału video

Informacja ze strony aktualności ODS PTI

Niby zdefiniowanie serwera zlinkowanego do Oracle nie powinno być trudne. Jest sporo tutoriali, które pokazują jak to zrobić. Kiedy jednak coś nie chce zadziałać – robi się ciekawie.

Oto na co należy zwrócić uwagę:

1. Allow inprocess

we właściwościach profilera zaznacz Allow inprocess. Ta zmiana wymaga niestety późniejszego wykonania restartu SQL

2. TNS_ADMIN

Uruchom CMD, wpisz polecenie SET, wyświetlające zdefiniowane zmienne środowiskowe. Wśród tych zmiennych powinna występować również zmienna TNS_ADMIN wskazująca na lokalizację pliku definiującego lokalizację baz danych Oracle

3. PATH

W podobny sposób zweryfikuj czy katalog w którym jest zainstalowany Oracle oraz podkatalog bin znajdują się w ścieżce. Zależnie od katalogu w jakim zainstalowano Oracle ścieżka ta może się różnić:

Path=D:\applications\Oracle;D:\applications\Oracle\bin;…. and the others

4. Uprawnienia

Upewnij się, że konto MSSQL ma dostęp do katalogów i lokalizacji wskazanych w poprzednich punktach.

Kiedy wysyłasz wynik zapytania jako załącznik do maila korzystając z procedury sp_send_db_mail dzieją się dwie brzydkie rzeczy:

• do wygenerowanego pliku dołaczany jest tekst np 3 row(s) affected
• między nagłówkiem a danymi pojawia się kreska rozdzielająca te dwa elementy ———————————–

Z pierwszym problemem dosyć łatwo sobie można poradzić. W przekazywanym parametrze @query zamiast samego zapytania, np.:

SELECT id, name FROM database.dbo.table

zapisz

SET NOCOUNT ON;
SELECT id, name FROM database.dbo.table

Gorzej jednak z pomijaniem kreseczek… trzeba użyć sztuczki. Po pierwsze rezygnujemy z generowania nagówka dodając do sp_send_db_mail parametr: @query_result_header = 0

A jak teraz dodać warunek? Zapytanie zmień na UNION dwóch zapytań. Pierwsze z nich wygeneruje to co ma być w załączniku, a drugie zwróci właściwe dane. W efekcie mamy więc:

SET NOCOUNT ON;
SELECT 'id' AS id, 'name' AS name 
UNION ALL
SELECT id, name FROM database.dbo.table

Podczas wysyłania maila z załącznikiem (który jest wynikiem zapytania) pojawiał się bład:

Failed to initialize sqlcmd library with error number -2147024809

O co chodzi? Otóż polecenie wysyłające maila:

 EXEC msdb..sp_send_dbmail @profile_name='SQLProfile'
 , @recipients = @EmailRecipient
 , @subject = @EmailSubject
 , @body = @EmailContent
 , @body_format = 'HTML'
 , @query=@EmailQuery
 , @attach_query_result_as_file=1
 , @query_attachment_filename = 'Results.csv'
 , @query_result_separator = ','
 , @from_address = 'sql-team@company.com'
 , @reply_to = 'sql-team@company.com'

wykonywało query zdefiniowane tak:

SELECT name from dbo.table

sęk w tym, że w czasie wysyłania maila wcale nie jest to takie jasne w jakiej bazie danych jesteśmy… Wystarczyło zmienić zapytanie na następującą postać żeby zadziałało:

SELECT name from mydatabase.dbo.table

Zazwyczaj, konta w AD nie mają przypadkowych nazw. Nazwy muszą być nadawane zgodnie z przyjętą polityką. Np nazwy użytkowników mogą zawierać pierwsze litery nazwiska, a nazwy kont serwisowych mogą określać  środowiska w jakich są wykorzystywane, jakie usługi będą z nich korzystać, na jakich serwerach itp.

W takim przypadku dość łatwo przeprowadzić inwentaryzację kont wykorzysywanych przez daną aplikację na danym serwerze lub w danym środowisku. Wystarczy do tego takie polecenie:

Get-ADUser -Filter "name -like 'sys*sql*p'" | Select name| Sort name

Zakładając, że konwencja nazewnicza

• kontom wykorzystywanym przez usługi określa nazwy rozpoczynające się od SYS
• kontom wykorzystywanym przez SQL określa występowanie w nazwie liter SQL
• kontom wykorzystywanym w środowisku produkcyjnym nadaje nazwy kończące się na P

powyższe polecenie wyświetli najprawdopodobniej właśnie konta usług SQL w środowisku produkcyjnym. Filtry mogą być oczywiście o wiele bardziej złożone!