Migracja modelu danych wersji 2.2 do 3.0¶

Ten rozdział opisuje mechanizmy migracji obiektów modelu danych Wheel Fudo PAM 2.2 do wersji 3.0.

Informacja

W przypadku niepowodzenia aktualizacji Wheel Fudo PAM do wersji 3.0, nieprawidłowości, które uniemożliwiły prawidłowe zakończenie migracji danych, zostaną zapisane w dzienniku zdarzeń.

Serwer ¶

Serwery o tym samym adresie IP i numerze portu zostają zastąpione jednym obiektem. Nazwa powstałego obiektu stanowi konkatenację nazw serwerów, posortowanych rosnąco i oddzielonych przecinkiem.

Ostrzeżenie

Jeżeli dwa serwery o tym samym adresie docelowym i porcie mają przypisane różne protokoły, opisy, ustawienia zewnętrznego repozytorium haseł, poziom bezpieczeństwa RDP, ustawienia HTTP, ustawienia TLS, certyfikaty lub klucze publiczne, aktualizacja nie powiedzie się.

Sejf (dawniej połączenie)¶

Połączenie anonimowe staje się obiektem typu sejf, który może zostać usunięty.
Dla każdego bastionu (tj. grupy serwerów w trybie bastion, przypisanych do tego samego bastionu) z danego połączenia zostaje utworzony obiekt typu sejf o nazwie <nazwa połączenia> > <nazwa bastionu>.
Dla każdego serwera w trybie gateway, proxy lub transparent z danego połączenia zostaje utworzony obiekt typu sejf o nazwie <nazwa połączenia> > <nazwa serwera>.
Sejf utworzony na podstawie połączenia dziedziczy po nim jego prawa dostępu, uprawnienia, ustawienia powiadomień, ustawienia protokołów, a także mapowania LDAP.
Ustawienia OCR, nagrywania sesji i retencji danych sesji nie są dziedziczone po połączeniu, ale znajdują swoje odzwierciedlenie w obiekcie typu konto.
Polityki czasowe połączeń odwzorowane są na dostęp użytkownika do sejfu utworzonego na podstawie danego połączenia.
Polityki danych logowania połączenia są odwzorowane na polityki sejfu.

Konto (dawniej dane logowania)¶

Dla każdych danych logowania z połączenia powstaje obiekt typu konto.

Jeżeli dane logowania zawierają login to konto dostaje typ regular. Nazwa takiego konta to <login> @ <ostateczna nazwa serwera>.
Jeżeli dane logowania nie zawierają loginu i dotyczą połączenia nieanonimowego, to konto dostaje typ forward. Nazwa takiego konta to forward for <ostateczna nazwa serwera>.
Jeżeli dane logowania nie zawierają loginu i dotyczą połączenia anonimowego to konto będące wynikiem migracji danych będzie typu anonymous. Nazwa takiego konta to anonymous for <ostateczna nazwa serwera>.
Zduplikowane dane logowania zostają zastąpione jednym kontem. Uprawnienia do zarządzania obiektem, ustawienia OCR, ustawienia nagrywania sesji, ustawienia retencji danych sesji konta zostają odziedziczone po połączeniu, z którego pochodziły dane logowania, na podstawie których konto zostało utworzone.

Ostrzeżenie

Jeżeli dane logowania zawierają login, ale nie zawierają sekretu, tzn. zastępują login, ale nie przekazują sekretu to aktualizacja zakończy się niepowodzeniem.

Gniazdo nasłuchiwania (dawniej bastion lub część serwera)¶

Dla każdego serwera w trybie proxy, transparent lub gateway zostaje utworzone gniazdo nasłuchiwania z tym samym trybem.
Obiekt dziedziczy po serwerze uprawnienia, ustawienia TLS i poziom bezpieczeństwa RDP.
Komunikat i klucze prywatne przechodzą na gniazdo.
Obiekt zostaje przypisany do wszystkich sejfów, które zostały utworzone na podstawie połączeń, do których należał serwer, z którego powstało gniazdo.
Bastion staje się gniazdem nasłuchiwania w trybie bastion. Prawa dostępu i ustawienia bastionu przechodzą na gniazdo. Gniazdo zostaje dodane do wszystkich sejfów, które zostały utworzone na podstawie połączeń, do których należał przynajmniej jeden serwer z bastionu, z którego powstało gniazdo.

Sesje¶

Dla każdej sesji zaktualizowany jest identyfikator sejfu, serwera i konta. Jeżeli sesja dotyczyła serwera, który nie działał w trybie bastion to również ustawiony jest identyfikator gniazda nasłuchiwania.