Brak dostępu do mandanta

Sytuacja z którą zetknęło się wielu administratorów – mamy system SAP ABAP (R/3, ERP, S/4HANA itp.) pełniący rolę systemu konfiguracyjnego lub testowego i w systemie tym kilka mandantów, służących określonym celom (konfiguracja, testy jednostkowe, testy akceptacyjne itp.).  Czasem jednak spoglądając do transakcji SCC4 dostrzegamy mandanty które nie są użytkowane:

 

Rys1. Przegląd mandantów w systemie

 

Na powyższej ilustracji widzimy mandant 000 – czyli mandant dostarczony przez SAP służący między innymi jako źródło do tworzenia (przez kopiowanie) nowych mandantów w systemie, mandant 100 – służący działaniom rozwojowym i deweloperskim i mandant 200 – no właśnie, obecnie nie służący niczemu. Użytkownicy kluczowi którzy lat temu kilka brali udział we wdrożeniu systemu pamiętają że na tym mandancie robione były testy migracji danych z poprzednio używanych systemów zanim jeszcze zainstalowano system testowy, nie udało się znaleźć jednak nikogo kto w chwili obecnej mógłby się do mandanta zalogować.  Z dokumentacją haseł użytkowników administracyjnych (SAP*, DDIC) do tego rodzaju „dodatkowych”, założonych „na chwilę” (czasem ta „chwila” trwa lata…)  mandantów też bywa różnie, często po prostu nie są one odnotowane w żadnym dokumencie przechowywanym bezpiecznie (sejf, nośnik zabezpieczony kryptograficznie).

Mamy więc mandant do którego nie możemy się zalogować, co rodzi następujące konsekwencje:

– nie jesteśmy w stanie przeprowadzić w nim audytu bezpieczeństwa – a nuż ktoś jednak się tam może zalogować i z użyciem narzędzi niezależnych od mandanta poczynić w systemie spustoszenia (choćby usuwając tabele z bazy danych);

– mandant zajmuje miejsce w bazie danych, zwiększa zajętość nośników backupowych;

– nie możemy mandanta usunąć (użycie transakcji SCC5 wymaga wcześniejszego zalogowania do mandanta usuwanego.

 

Czynności wstępne

Reasumując – potrzebny jest sposób który pozwoli nam zalogować się użytkownikiem z szerokimi uprawnieniami do tego „zapomnianego” mandanta.  Od czego zacząć?
Po pierwsze – od uruchomienia w innym mandancie (w naszym przykładzie – w mandancie 000 lub 100) raportu RSUSR003 który bada czy istnieją użytkownicy SAP* i DDIC i czy dla tych użytkowników zostały użyte hasła standardowe:

 

 

 

Rys2. Rezultat raportu RSUSR003

 

Jeśli raport wykaże że dla użytkownika SAP* i DDIC użyte zostały hasła standardowe to zostaje nam spojrzeć do noty SAP 8852 lub 389530 by je odnaleźć.   W naszym przykładzie tak nie jest – w mandancie 200 użytkownik DDIC nie istnieje, użytkownik SAP* ma hasło inne od standardowego.

W takim przypadku doprowadzić trzeba do sytuacji w której:

– parametr login/no_automatic_user_sapstar  będzie miał wartość 0

– w mandancie do którego się chcemy zalogować nie będzie zdefiniowanego użytkownika SAP*

Spełnienie tych dwu warunków pozwoli nam zalogować się do mandanta użytkownikiem SAP* z hasłem domyślnym pass.

Parametr  login/no_automatic_user_sapstar  w naszym przykładowym systemie ma wartość 1 (proszę spojrzeć wyżej,  na ekran raportu RSUSR003) – tą wartość możemy zmienić logując się do innego mandanta i używając transakcji RZ10.

 

 

 

Rys3. Zmiana parametru   login/no_automatic_user_sapstar

 

Po zmianie (lub dodaniu) parametru pamiętajmy o zapisaniu i aktywowaniu zmienionego profilu.

 

 

Rys4. Aktywacja zmian w profilu

 

By zmiana w profilu odniosła skutek trzeba jeszcze zrestartować instancję aplikacyjną SAP – przy pomocy konsoli MC, konsoli MMC lub poleceń systemu operacyjnego.

 

Usuwanie użytkownika SAP*

Jak usunąć użytkownika SAP* z mandanta do którego chcemy się zalogować?  Z braku dostępu do mandanta użycie transakcji SU01 odpada, ale pozostaje możliwość usunięcia użytkownika przy pomocy narzędzi bazodanowych z poziomu systemu operacyjnego serwera.

W przypadku naszego przykładowego systemu S6t w użyciu jest baza danych MaxDB i system operacyjny Linux.

Będą nam potrzebne następujące dane:

– parametry logowania użytkownika <sid>adm na poziomie systemu operacyjnego serwera bazy danych

– nazwa bazy danych

– nazwa użytkownika który jest właścicielem schematu w bazie danych przechowującego tabele systemu SAP

– hasło użytkownika który jest właścicielem schematu w bazie danych

Parametry logowania użytkownika <sid>adm zwykle mamy pod ręką, nazwę bazy danych i nazwę użytkownika który jest właścicielem schematu w bazie danych ustalimy logując się do systemu SAP i na  dowolnym ekranie wybierając z menu opcje System / Status:

 

 

 

Rys5. Ustalanie nazwy użytkownika – właściciela schematu w bazie

 

Uwaga:

Poniżej użyte są składnia SQL i narzędzie SQL właściwe dla bazy danych MaxDB.   W przypadku innej bazy muszą być użyte narzędzie i składnia właściwe dla tej bazy danych.

Logujemy się do serwera poprzez ssh na użytkownika <sid>adm (w naszym przypadku s6tadm) i wywołujemy polecenie:

sqlcli  -d <DBN> -u <USER>,<password>

Gdzie:

sqlcli – narzędzie SQL linii poleceń

<DBN> – nazwa bazy danych (3 znakowa)

<USER> – nazwa użytkownika który jest właścicielem schematu w bazie danych

<password> – hasło użytkownika który jest właścicielem schematu w bazie danych

W naszym przykładzie linia wywołania będzie wyglądać tak:

sqlcli  -d S6T -u SAPS6T,qqa41mfr

 

 

 

 

Po wywołaniu narzędzia sqlcli pojawia się prompt zapytań SQL, możemy więc poleceniem select wylistować rekordy z tabel systemu SAP lub poleceniem delete wybrany rekord z tabeli usunąć.

 

Uwaga:

W każdym przypadku działania z użyciem narzędzia SQL zaleca  się poprzedzić sporządzeniem backupu bazy.  Jakakolwiek pomyłka może mieć dotkliwe skutki, przykładowo przypadkowe usunięcie wszystkich wpisów z tabeli USR02 pozbawi nas całej kartoteki użytkowników systemu – wszystkich mandantów!

Upewnijmy się więc że mandancie 200 istnieje użytkownik SAP*.  Kartoteka użytkowników przechowywana jest w tabeli usr02, kolumna MANDT zawiera numer mandanta, kolumna BNAME – nazwę użytkownika (tabela ma rzecz jasna o wiele więcej kolumn, ich zawartość w tym przypadku jest poza naszym zainteresowaniem).  Wykonajmy więc zapytanie SQL kończąc je naciśnięciem klawisza <ENTER>:

select  MANDT, BNAME from usr02 where MANDT = ‘200’ and BNAME = ‘SAP*’

 

 

 

 

Jak widać został wylistowany rekord użytkownika SAP* w mandancie 200.

Rekord ten chcemy usunąć, w tym celu posłużymy się poleceniem SQLowym delete:

delete  from usr02 where MANDT = ‘200’ and BNAME = ‘SAP*’

 

 

 

 

Jak widzimy skutkiem przebiegu polecenia delete usunięty został jeden rekord z tabeli usr02 bazy danych, powtórzmy więc polecenie select by przekonać się że   rekord użytkownika SAP* w mandancie 200 zniknął:

 

 

 

 

Jak widać – użytkownika SAP* w mandancie 200 już nie ma.

Pracę z narzędziem SQL kończymy poleceniem exit:

 

 

 

 

Jeśli w tabeli USR02 brak użytkownika SAP*  dla mandanta 200 i w systemie parametr login/no_automatic_user_sapstar   ma wartość 0 to możemy przystąpić do próby zalogowania użytkownika SAP*  z użyciem hasła pass – to hasło jest zapisane w kodzie mechanizmu autoryzacji i można go użyć jedynie gdy są spełnione dwa powyżej opisane warunki:

 

 

 

Rys6. Próba zalogowania użytkownika SAP*

 

Czynności końcowe

Dalsze działania po zmianie hasła powinny obejmować:

– utworzenie użytkownika SAP* w mandancie

– utworzenie użytkownika do celów administracyjnych, zaopatrzonego w odpowiednie autoryzacje

– zmianę wartości parametru login/no_automatic_user_sapstar   na 0 (transakcja RZ10)

– restart instancji systemu

Po wykonaniu tych czynności mamy dostęp do mandanta i możemy przeprowadzić czynności związane z jego usunięciem, analizą bezpieczeństwa itp.