Połączenie do Microsoft SQL Server z poziomu Comarch OPT!MA

Biuletyn techniczny Comarch OPT!MA 17.0 Połączenie do Microsoft SQL Server z poziomu Comarch OPT!MA Data powstania: 3.03.2008 r. Data aktualizacji: 8.07.2008 r. Data aktualizacji: 19.11.2009 r. Copyright 2007-2009 COMARCH SA

Spis treści 1 WPROWADZENIE... 3 2 KOMUNIKACJA MIĘDZY COMARCH OPT!MA A SERWEREM MICROSOFT SQL SERVER... 3 2.1. KONFIGURACJA BIBLIOTEK I PROTOKOŁÓW SIECIOWYCH... 3 2.2. NAWIĄZYWANIE POŁĄCZENIA Z SERWEREM... 5 2.3. LOGOWANIE DO SERWERA SQL... 7 2.3.1. KONFIGURACJA ZABEZPIECZEŃ NA SERWERZE SQL DLA COMARCH OPT!MA... 8 2.3.2. POŁĄCZENIE DO BAZY KONFIGURACYJNEJ... 9 2.3.3. POŁĄCZENIE DO BAZY FIRMOWEJ... 10 2.4. UWIERZYTELNIENIE W PROGRAMIE COMARCH OPT!MA... 13 3 POŁĄCZENIE Z COMARCH OPT!MA POPRZEZ USŁUGI TERMINALOWE... 13 4 POŁĄCZENIE Z SERWEREM SQL PRZEZ VPN... 14 Str. 2

1 Wprowadzenie Celem biuletynu jest przedstawienie komunikacji między aplikacją Comarch OPT!MA a serwerem Microsoft SQL Server, aby pomóc w rozwiązywaniu problemów z nawiązywaniem połączeń z serwerem. Więcej informacji o najczęściej pojawiających się problemach z połączeniami moŝna znaleźć na stronie http://faq.klient.comarch.pl 2 Komunikacja między Comarch OPT!MA a serwerem Microsoft SQL Server Komunikację aplikacji Comarch OPT!MA z serwerem SQL moŝemy podzielić na cztery etapy. Pierwszy z nich to wywołanie Ŝądania połączenia z serwerem z poziomu programu. śądanie to jest przekazywane do bibliotek sieciowych systemu operacyjnego, za pomocą których nawiązywane jest połączenie z serwerem etap drugi. Po udanym połączeniu następuje trzeci etap, którym jest logowanie do serwera SQL. Na zakończenie w czwartym etapie konieczne jest uwierzytelnienie uŝytkownika w programie Comarch OPT!MA. Konfiguracja bibliotek i protokołów sieciowych Nawiązanie połączenia z serwerem Logowanie do serwera SQL Uwierzytelnienie uŝytkownika w Comarch OPT!MA 1 2 3 4 Rysunek 1 2.1. Konfiguracja bibliotek i protokołów sieciowych Aplikacja Comarch OPT!MA chcąc połączyć się z serwerem wywołuje odpowiednią funkcję umoŝliwiającą przesłanie zapytania SQL do serwera. Aby było to moŝliwe w systemie klienta muszą być zainstalowane i poprawnie działające biblioteki, które posiadają takie funkcje. Comarch OPT!MA do połączeń z serwerem SQL wykorzystuje biblioteki ADO, OLE DB oraz ODBC. Zawarte są one w komponencie o nazwie MDAC który jest integralną częścią systemów operacyjnych Windows 2000/XP/2003 (komponent nazywa się WDAC w systemie Windows Vista). W sytuacji, gdy komponenty te z ulegną uszkodzeniu moŝe zajść potrzeba ich ponownego zainstalowania. Na płytce Comarch OPT!MA w katalogu <cdrom>\setup\mdac\ znajduje się komponenty MDAC w wersji 2.8 RTM. Reinstalacja nie dotyczy systemu Windows Vista. Procedura reinstalacji komponentów MDAC 1. Rozpakowanie pliku mdac_typ.exe Str. 3

mdac_typ.exe /C /T:c:\temp\mdacinst gdzie c:\temp\mdacinst jest ścieŝką, w której rozpakowany zostanie plik mdac_typ.exe 2. W katalogu, do którego rozpakowano mdac_typ.exe naleŝy odnaleźć plik mdacxpak.inf i pod prawym przyciskiem myszy wybrać opcję zainstaluj Uwaga: Przed uruchomieniem reinstalacji komponentów naleŝy wyłączyć wszystkie aplikacje, które mogą korzystać z bibliotek pozwalających na połączenie do bazy danych. W szczególności naleŝy wyłączyć program Comarch OPT!MA, wszystkie moduły dodatkowe takie jak Comarch OPT!MA Detal, Comarch OPT!MA Biuro Rachunkowe, Comarch OPT!MA Migrator, Comarch OPT!MA Przypominacz, Comarch Synchro, czy Comarch OPT!MA Ofertowanie. Wyłączone teŝ muszą być serwery SQL na tym komputerze. 3. Wykonać restart komputera Konfiguracja protokołów sieciowych W celu prawidłowej komunikacji z serwerem SQL, musi on prowadzić nasłuch na określonych protokołach. Ustawienia protokołów dla Microsoft SQL Server 2000 moŝna wykonać w narzędziu svrnetcn, które domyślnie znajduje się w katalogu c:\program Files\Microsoft SQL Server\80\Tools\Binn\. W przypadku Microsoft SQL Server 2005 ustawiania protokołów moŝna wykonać za pomocą narzędzia SQL Server Configuration Manager. Uwaga! Przy instalacji Microsoft SQL Server 2005 Express domyślnie wyłączony jest nasłuch na protokole TCP. Protokoły, na których nasłuchuje serwer moŝna równieŝ sprawdzić w pliku errorlog, który znajduje się w podkatalogu LOG instancji serwera (dla MS SQL 2000 domyślnie w: C:\Program Files\Microsoft SQL Server\MSSQL$nazwa_instancji\LOG\, dla MS SQL 2005 domyślnie w: C:\Program Files\Microsoft SQL Server\MSSQL.x\MSSQL\LOG\). Więcej informacji na temat prawidłowej konfiguracji protokołów moŝna znaleźć w biuletynie: OPT019- Konfiguracja połączenie z serwerem MSSQL 2000 https://www.cdn.com.pl/cdnpartnerzy/biuletyny/pliki_optima/opt019-konfiguracjamssql.pdf) oraz OPT031-CDN OPT!MA a SQL 2005 https://www.cdn.com.pl/cdnpartnerzy/biuletyny/pliki_optima/opt031- CDN%20OPT!MA%20a%20SQL%202005.pdf Str. 4

2.2. Nawiązywanie połączenia z serwerem NAWIĄZANIE POŁĄCZENIA MIĘDZY KLIENTEM A SERWEREM MS SQL 2000 1 rozwiązanie nazwy serwera na adres ip 2 4 wyjątek w zaporze: Udostępnianie plików i drukarek 3 port UDP 137 Proces System port UDP 1434 listener port TCP KLIENT wyjątek w zaporze dla procesu serwera sqlserv.exe proces serwera Zapora sieciowa SERWER Rysunek 2 Str. 5

NAWIĄZANIE POŁĄCZENIA MIĘDZY KLIENTEM A SERWEREM MS SQL 2005 wyjątek w zaporze: Udostępnianie plików i drukarek port UDP 137 Proces System rozwiązanie nazwy 1 serwera na adres ip KLIENT 4 2 3 wyjątek w zaporze dla procesu sqlbrowser port UDP 1434 port TCP domyślnie ustalany dynamicznie sqlbrowser.exe wyjątek w zaporze dla procesu serwera sqlserv.exe proces serwera Zapora sieciowa SERWER Rysunek 3 Etapy nawiązania połączenia z serwerem SQL: 1. Rozwiązanie nazwy serwera na adres IP, w tym celu najczęściej* klient wysyła zapytanie typu broadcast do swojej podsieci IP na porcie 137 UDP. JeŜeli znajduje się w tej podsieci komputer o takiej nazwie to odpowiada on na zapytanie podając swój adres IP. JeŜeli komputer klienta nie moŝe rozwiązać nazwy serwera poniewaŝ ten ma np. zablokowany port 137 UDP, to komunikacja z serwerem kończy się na tym etapie. *Więcej informacji na temat rozwiązywania nazw przez system Windows moŝna znaleźć tutaj: http://technet2.microsoft.com/windowsserver/en/library/468276dc-7ff0-4c42-8937- 305bc26487331033.mspx?mfr=true 2. Nawiązanie połączenia z listenerem serwera SQL na porcie UDP 1434 (Microsoft SQL Server 2000) w celu uzyskania informacji o dostępnych instancjach i portach na jakich nasłuchują. W przypadku Microsoft SQL Server 2005 listener został wydzielony do odrębnej usługi o nazwie sqlbrowser, jednakŝe pełni te same funkcje co listener w Microsoft SQL Server 2000 i nasłuch prowadzony jest na tym samym porcie. 3. Serwer zwraca listę dostępnych instancji oraz portów na jakich nasłuchują 4. Aplikacja łączy się z Ŝądaną instancją na zwróconym przez serwer porcie tcp. Str. 6

Ustawienia zapory sieciowej W celu nawiązania połączenia z serwerem musi być zapewniony mechanizm rozwiązywania nazw (więcej informacji: http://technet2.microsoft.com/windowsserver/en/library/468276dc-7ff0-4c42-8937- 305bc26487331033.mspx?mfr=true). Rozwiązywanie nazw bez dodatkowej konfiguracji na stacjach klienckich wymaga włączenie w zaporze sieciowej na serwerze wyjątku Udostępnianie plików i drukarek. Prócz tego, aby umoŝliwić przyjmowanie połączeń do serwera SQL muszą być dodane wyjątki dla aplikacji sqlservr.exe, a w przypadku SQL Server 2005 dodatkowo takŝe naleŝy dodać wyjątek dla usługi sqlbrowser. Wyjątki dla sqlservr.exe oraz sqlbrowser.exe (jako aplikacji) dodawane są do zapory sieciowej windows podczas instalacji Comarch OPT!MA, gdy zaznaczymy opcję Udostępnij bazę danych dla innych stanowisk. MoŜna je równieŝ dodać poprzez instalację serwisu klucza HASP (HASPInstall.exe), który znajduje się stronie http://www.cdn.com.pl/klienci/default.aspx?site=2211 lub http://www.cdn.pl/partnerzy/default.aspx?site=433). NaleŜy równieŝ pamiętać o sprawdzeniu, czy na serwerze nie pracują zapory sieciowe innych producentów. Zasada dodawania wyjątków jest podobna, potrzebne są wyjątki dla programów sqlservr.exe oraz sqlbrowser.exe (w przypadku SQL Server 2005). Prócz tego naleŝy pamiętać o wyjątku umoŝliwiającym rozwiązywanie nazw (w tym celu naleŝy udostępnić port UDP/137). Rysunek 4 2.3. Logowanie do serwera SQL Serwer SQL pozwala na logowanie w dwóch trybach. Pierwszy z nich to tzw. Windows authentication (w Comarch OPT!MA nosi on nazwę autentykacja przez domenę NT ). Polega on na tym, Ŝe uŝytkownicy logują się do serwera SQL, z poświadczeniami związanymi z kontem, na którym pracują w Str. 7

systemie Windows. JednakŜe są uwierzytelniani nie na serwerze SQL, ale przez mechanizmy systemu Windows. Drugi tryb logowania to tryb mieszany, który prócz moŝliwości logowania poprzez Windows authentication, pozwala równieŝ na uwierzytelnienie na serwerze SQL za pomocą loginów SQL. Loginy te wraz z hasłami są tworzone i przechowywane na serwerze SQL. Do loginów SQL zaliczamy np. konto administracyjne sa. Ustawienie trybu Windows authentication na serwerze SQL nie pozwala na logowanie za pomocą loginów SQL. Uwaga: Program Comarch OPT!MA do prawidłowej pracy ustawienia trybu mieszanego (ang. mixed mode) jako medoty uwierzytelnienia na serwerze SQL. Loginom (czyli loginom SQL lub kontom z systemu Windows) w serwerze SQL mogą być nadawane role, które powodują przyznanie im uprawnień na poziomie całego serwera. Więcej informacji na temat ról serwera moŝna przeczytać tutaj: http://msdn2.microsoft.com/en-us/library/ms188659.aspx. Ustawienia uprawnień w samej bazie danych nie odbywa się na poziomie loginów, a uŝytkowników. UŜytkownicy są jeszcze jednym poziomem zabezpieczeń. To uŝytkownicy mają nadawane prawa odczytu, zapisu lub wykonywania procedur, czy funkcji. W konfiguracji serwera istnieje powiązanie między loginem, a uŝytkownikiem w bazie. Podczas instalacji serwera tworzony jest między innymi login systemowy sa, który ma przypisaną rolę sysadmin, sprawia to, Ŝe login ten ma pełne uprawnienia na serwerze SQL. Oprócz sa rolę sysadmin posiadają równieŝ członkowie grupy Administratorzy (BUILTIN\Administratorzy), na komputerze gdzie instalowany jest serwer SQL. 2.3.1. Konfiguracja zabezpieczeń na serwerze SQL dla Comarch OPT!MA Aplikacja Comarch OPT!MA podczas konfiguracji serwera SQL tworzy specjalne loginy SQL: cdnoperator, cdngosc oraz cdnhasp. Login cdnoperator jest podstawowym wewnętrznym loginem uŝywanym przez Comarch OPT!MA do komunikacji z bazą danych. Posiada on odpowiadającego sobie uŝytkownika cdnoperator, który ma nadaną rolę CDN oraz Public we wszystkich bazach Comarch OPT!MA firmowych oraz konfiguracyjnych. Rola db_owner nadawana jest automatycznie po włączeniu roli CDN. Login cdnhasp jest wykorzystywany do weryfikacji posiadanych licencji. Więcej informacji na temat loginów moŝna znaleźć w biuletynie OPT020-MSSQL2000 i Comarch OPT!MA.pdf Str. 8

Rysunek 5 2.3.2. Połączenie do bazy konfiguracyjnej Bazę konfiguracyjną moŝemy podłączyć korzystając z trybu Autoryzacja na serwerze SQL lub Autoryzacja przez domenę NT, które moŝemy wybrać w kreatorze Przygotowanie do uruchomienia systemu. Str. 9

Rysunek 6 Po udanym połączeniu jego parametry zapisywane są w rejestrze systemowym w gałęzi: HKEY_CURRENT_USER\Software\CDN\CDN OPT!MA\CDN OPT!MA\Login\KonfigConnectStr np. NET:CDN_Konfiguracja,SERWER\CDN_OPTIMA,NT=0 gdzie: CDN_Konfiguracja nazwa bazy konfiguracyjnej, SERWER\CDN_OPTIMA serwer bazy danych, NT=0 Autoryzacja na serwerze SQL (NT=1 Autoryzacja przez domenę NT). 2.3.3. Połączenie do bazy firmowej Połączenie z bazą firmową moŝe być równieŝ realizowane poprzez Autoryzację na serwerze SQL lub Autoryzację przez domenę NT. Wyboru między tymi dwoma trybami moŝna dokonać w konfiguracji programu Menu System Konfiguracja Zakładka Program UŜytkowe Bazy danych Modyfikuj informacje o bazie danych Parametr: Login zintegrowany NT Rysunek 7 Zaznaczenie parametru Login zintegrowany NT spowoduje ustawienie trybu łączenia z bazą firmową na Autoryzację przez domenę NT. Natomiast pozostawienie niezaznaczonego parametru ustawia tryb Autoryzacja na serwerze SQL. Konfiguracja dostępu do bazy firmowej z wykorzystaniem Autoryzacji przez domenę NT. 1. Utworzenie loginu Windows Login moŝna utworzyć korzystając z narzędzia Microsoft SQL Server 2005 Management Studio. Po połączeniu do instancji serwera naleŝy rozwinąć zakładkę Security i kliknąć prawym klawiszem myszy na zakładkę Logins i wybrać opcję New Login Str. 10

Rysunek 8 W formularzu tworzonego uŝytkownika na pierwszej zakładce General naleŝy podać pełną nazwę uŝytkownika lub grupy. Jako pierwszy człon nazwy podajemy nazwę komputera lub domeny, w której uŝytkownik jest zalogowany. Następnie po znaku \ podajemy nazwę uŝytkownika. Dodatkowo zaznaczamy opcję Windows Authentication. Uwaga: W celu dodania uŝytkownika związanego z komputerem innym niŝ ten, na którym zainstalowany jest serwer SQL konieczne jest na serwerze załoŝenie uŝytkownika na poziomie systemu operacyjnego o takiej samej nazwie i takim samym haśle jak ten, który loguje się na końcówce. Str. 11

Rysunek 9 Na zakładce Server Roles pozostawiamy przypisanie do roli public, opcjonalnie moŝna przypisać login równieŝ do innej roli. Str. 12

Rysunek 10 Na zakończenie zaznaczamy bazy Comarch OPT!MA, do których ma mieć dostęp dany login. Następnie dla tych baz nadajemy odpowiadającemu uŝytkownikowi w bazie rolę CDN oraz public. Rysunek 11 2. Przestawienie logowanie do bazy firmowej na tryb Autoryzacja przez domenę NT Przestawienie logowania ustawiamy poprzez zaznaczenie parametru Login zintegrowany NT (patrz początek p. 3.3) 2.4. Uwierzytelnienie w programie Comarch OPT!MA Ten punkt nie wymaga większych wyjaśnień. Comarch OPT!MA do uwierzytelnienia uŝytkowników wykorzystuje loginy i przypisane im hasła, które są przechowywane w bazie danych. Mogę one być tworzone, usuwane i modyfikowane z poziomu aplikacji. Od wersji 14 Comarch OPT!MA wprowadzono wymuszanie sprawdzania złoŝoności hasła wprowadzanego dla operatora. Silne hasło powinno być nie krótsze niŝ 8 znaków, zawierać litery od A do Z oraz od a do z, cyfry 0-9 oraz znaki specjalne '!@#$%^&*()_+-=[]{},;:.?/. 3 Połączenie z Comarch OPT!MA poprzez usługi terminalowe Konfiguracja programu Comarch OPT!MA poprzez usługi terminalowe jest zalecanym sposobem pracy na wspólnej bazie przez uŝytkowników z róŝnych lokalizacji firmy. Ten tryb pracy wymaga systemu Str. 13

Windows Server ze skonfigurowanymi usługa terminalowymi. Prócz tego na serwerze musi być zainstalowana aplikacja Comarch OPT!MA. Klienci łączą się do serwera za pomocą klienta zdalnego pulpitu. Aplikacja uruchomiana jest na serwerze terminali, a do klienta przesyłany jest obraz pulpitu. Ma to zaletę w stosunkowo niskim zapotrzebowaniu na przepustowość. Do normalnej pracy dla jednego połączenia wystarczy przepustowość rzędu 60 kbit/s. JeŜeli chodzi o łącze w lokalizacji, gdzie znajduje się serwer to naleŝy pamiętać, Ŝe istotnym parametrem jest przepustowość od komputera (tzw. upstream). W ofercie operatorów znajdują się między innymi łącza o asymetrycznej przepustowości, to znaczy takiej, której wartość jest róŝna do i od komputera. Operatorzy na pierwszym miejscu podają większą wartość czyli do komputera. NaleŜy sprawdzić w ofercie jaka jest przepustowość od komputera. Jej wartość powinna być co najmniej równa maksymalnej ilości uŝytkowników łączących się poprzez zdalny pulpit pomnoŝoną razy 60 kbt/s (oczywiście przy załoŝeniu, Ŝe łącze wykorzystywane jest wyłącznie do pracy z usługami terminalowymi). Więcej informacji na temat usług terminalowych i ich konfigracji moŝna znaleźć między w poniŝszych odnośnikach: http://www.microsoft.com/poland/windowsserver2003/artykuly/uslugi_terminalowe.mspx http://technet2.microsoft.com/windowsserver/pl/library/d3d28279-ae43-41ab-bc43- b0e5bd1d0fe01045.mspx?mfr=true 4 Połączenie z serwerem SQL przez VPN Jak wspomniano w punkcie 5 Połączenie z Comarch OPT!MA poprzez usługi terminalowe zalecanym sposobem pracy zdalnej na wspólnej bazie są usługi terminalowe. JednakŜe jeŝeli zachodzi konieczność wykorzystania bezpośredniego połączenia do serwera przez łącza WAN (np. Internet) to zdecydowanie zalecane jest wykorzystanie dodatkowych zabezpieczeń połączenia w postaci mechanizmu VPN (Virtual Private Network). JednakŜe naleŝy się liczyć z tym, Ŝe przy takiej konfiguracji będzie zauwaŝalne spowolnienie pracy programu. Wynika to stąd, Ŝe przy bezpośrednim połączeniu do serwera między aplikacją, a serwerem wymieniane są znaczące ilości danych. Przy połączeniu przez kanał wirtualny naleŝy pamiętać o utworzeniu aliasu do serwera SQL, gdzie jest baza Comarch OPT!MA. Jest to konieczne poniewaŝ aplikacja wyszukuje serwera po nazwie za pomocą protokołu Netbios, który nie jest rutowalny, co oznacza, Ŝe nie jest przekazywany pomiędzy róŝnymi podsieciami IP. Alias do serwera moŝemy utworzyć za pomocą polecenia c:\windows\system32\cliconfg.exe. W definicji aliasu podajemy jego nazwę, która musi być taka sama jak nazwa serwera SQL (w konwencji nazwa_komputera\nazwa_instancji) Rysunek 12. W polu nazwa serwera w miejsce nazwa_komputera wpisujemy adres IP serwera. Opcjonalnie, aby pominąć krok związany z połączeniem do listenera serwera SQL (patrz p. 2.2), moŝna podać równieŝ port, na którym nasłuchuje instancja. Str. 14

Rysunek 12 Str. 15