Odzyskanie hasła użytkownika SYSDBA w KS SOMED

[yaho]

Witam Wszystkich
To moja pierwsza wizyta na forum, więc wybaczcie, jeśli poruszam być może już wielokrotnie oklepany wątek. Przejrzałem dość sporo postów nt użytkownika SYSDBA  i jego domyślnego hasła, czyli 'masterkey'. Mój kłopot polega na tym, że ta hasło nie działa. Próba aktualizacji bazy danych po udanym patch'owaniu wywala mi się na kroku, w którym jest próba logowania jako sysdba. I teraz zbadałem dwa przypadki:
1. Jeśli w rejetrze systemu w kluczu KSPL/XSYSPASS mam wpisaną wartość klucza identyczną, jak na stacji roboczej, dostaję "Błąd w dostępie do wzorca bazy. Unknown database. .... Klasa błędu: EDBEngineError)
2. Jeśli we wspomnianym kluczu wstawiam pustą wartość, dostaję "Błędnie podane hasło lub nazwa użytkownika. Jeśi hasło było zmieniane dla użytk SYSDBA, należy ja za każdym razem podać"
Nie przypominam sobie, abym świadomie  to hasło zmieniał. Jeśli już, to mogło sie to stać podczas dodawania stacji roboczej na 7, ale nie sądzę, aby się tak mogło stać, aby instalacja aplikacji na końcówce mogła wymusić zmianę hasła na bazie na serwerze. Jeśli ktoś miał podobne problemy - prośba o sugestie. Użytkownik GABINET/GM działa poprawnie.  Niemożliwa jest jednak aktualizacja bazy danych. Problem obecnie sprowadza się do tego, w jaki sposób ustalić obecne hasło lub powrócić do domyślnego masterkey'a.
dzięki/pozdrawiam
Yaho

[Paweł]

Jako, że nie znam się na somedzie ani oracle to może trzeba przeinstalować BDE?

[yaho]

Tak próbowałem, ponieważ liczyłem na to, że nadinstalowanie BDE powinno pomóc, niestety bez powodzenia. 
Spróbuję inaczej
http://www.firebirdfaq.org/faq55/,
ale jeśli ktoś ma jakiś sprawdzony sposób, byłbym wdzięczny.

pozdrawiam
Y

[ekspert1]

a czy mozesz sie zalogowac do bazy na sysdba?

[yaho]

Właśnie na tym polega kłopot, że nie mogę, ponieważ wywala mi błędy, jak na początku wątku. Działa natomiast na użytkowniku GABINET i gdyby nie potrzeba aktualizacji, to problemu może by nie było.

pozdrawiam
Y

[MK]

Witam
Spróbuj czymkolwiek zalogować się na sysdba próbując hasła masterkey. Jeśli się uda, problemem nie jest sam serwer.
Piszesz o stacji roboczej, więc pytanie, czy z innej stacji udaje się zalogować na sysdba? Jeśli to ten sam serwer, to nieważne skąd, zawsze powinno wyglądać tak samo, czyli albo się zalogujesz na to samo hasło, albo nie.

Jeśli ni jak i z żadnej końcówki nie da się zalogować na sysdba z hasłem masterkey to znacz, że jednak hasło było się zmieniło.

Jeśli nie znasz hasło, to cóż, KS-SOMED nic tu nie pomoże. I problem leży poza jego sferą kontroli. BDE też w niczym nie pomoże.  Pozostaje zgrać bazę odinstalować firebirda i zainstalować go ponownie (być może jest inna metoda na przywrócenie standardowego hasła, ale ja jej nie znam). Z tym odinstalowaniem to też nie do końca wiem, czy sam firebird ma dobry odinsalator (nigdy nie testowałem), czy też należy wszystko wyczyścić ręcznie, w każdym bądź razie, jeśli czyszczenie przebiegnie skutecznie, jest szansa, że ponowna instalacja spowoduje, że mamy firebirda z hasłem masterkey  na sysdba. Potem należy bazę przywrócić, usunąć na wszystkich stanowiskach wpisy xsyspass i uruchomić koniec instalacji. Założy on użytkownika gabinet z hasłem GM i powinno to spowodować, że już wszystko będzie po staremu.

[yaho]

Witam
Zrobiłem dość podobnie, jak pisze Kolega MK, tylko zamiast odinstalowywać poszczególne elementy, postawiłem najnowszą wersję na "czystym" laptopie, tzn bez wcześniejszych instalacji BDE i FB. Potem podmieniłem bazę i udało się do niej dobrać na obu użytkownikach ze standardowymi hasłami. Wniosek taki, że hasło do SYSDBA nie było zmienione. Po zaktualizowaniu bazy przeniosłem ją na serwer.  Tu nie poszło gładko, ale aplikacja ruszyła w nowej wersji. Na końcówkach odpaliłem ręczną instalację wersji 2013.0.00, ale nowe paczki już dały się załadować z serwera. Końcówki też wstały, mimo tego że nie uruchamiałem końca instalacji, jak podpowiada Kolega MK. I może tego zabrakło, bo dalej próba testu z poziomu stacji dla SYSDBA z masterkey'em  kończy się błędem.  No ale przynajmniej została podniesiona wersja. Jutro spróbuję jeszcze usunąć  xsyspass'y i dać koniec instalacji, chociaż mam wątpliwości, czy to pomoże. Tylko się zastanawiam, czy należy usunąć cały klucz, czy tylko jego wartość ? Dam znać, co z tego wyszło.

Dzięki serdeczne za wszelkie podpowiedzi.
pozdrawiam
Yaho

[MK]

To nie tak!
Użytkownicy i hasła siedzą na serwerze! Nie w pliku bazy danych!
Jeśli więc na nowym komputerze zainstalowałeś FB to oczywiście, że masz tam hasło standardowe do sysdba czyli masterkey. Oczywistym jest, że jak na ten serwer wgrasz plik bazy danych, to dostaniesz się do niego na sysdba z hasłem masterkey, gdyż jak pisałem, zarządza tym serwer, a masz go na nowo postawiony. To nie jest żaden dowód, że hasła nie zmieniałeś.
Dlatego pisałem o postawieniu serwera od nowa, bo to jedyny znany mi sposób "wyczyszczenia hasła".
Na marginesie, to, że hasła są pamiętane na serwerze i można spokojnie podmieniać plik bazy danych z jednej instalacji na drugą jest powodem, że FB jest systemem ciut mało bezpiecznym. Po prostu idę z pendriverm do przychodni, zgrywam plik bazy danych i mam w nosie wszelkie zabezpieczenia serwera FB, bo zainstaluję sobie takiego od nowa i bazę podłączę.
Aby jakoś zabezpieczyć instalację, należy:
1.   Zmienić hasło dla użytkownika GM, aby nikt nieupoważniony z końcówki nam dane nie wykradł, puszczając zwykłe SQLe.
2.   Zmienić hasło dla użytkownika sysdba, aby nikt nieupoważniony z końcówki nam dane nie wykradł, puszczając zwykłe SQLe, tudzież nie wykonał po prostu backupu bazy danych na własny dysk.
3.   Zabezpieczyć dostęp do pliku bazy danych, aby nikt z końcówki fizycznie pliku nam nie wyrwał. Jak mu się to uda, to tak jak opisałem wyżej, wszelkie poprzednie zabezpieczenia szlag trafi.
4.   Zabezpieczyć dostęp do serwera, aby nikt z nieupoważniony na serwer się nie zalogował i po prostu bazę zgrał.
5.   A na sam koniec zabezpieczyć serwer fizycznie (serwerownia z alarmem itp. itd.) aby maksymalnie utrudnić dostęp fizyczny do bazy danych.
Mam nadzieję, że teraz już jest jasnym, jak to z hasłami i bezpieczeństwem jest.

A wracając do tematu i podsumowując, opisana przez yaho procedura o niczym, no poza ukazaniem jak ukraść dane, nie świadczy. A na pewno nie świadczy o tym, że hasło na bazie nie było zmieniane

[mpi]

A jakby podmienić plik security2.fdb z tego innego komputera na którym jest sysdba z hasłem masterkey? To by coś pomogło? Czy zaszkodzi?

[MK]

Nie wiem, nigdy nie próbowałem.

[yaho]

Dzięki !
To faktycznie wyjaśnia parę rzeczy. Rozumiem, że aby całkowicie uzdrowić sytuację należy wpierw odinstalować z serwera FB i odpalić na nowo jego instalację (wcześniej próbowałem nadinstalować nowszą wersję, ale to nie pomagało). Czy tak samo należy zrobić z BDE ?
I jeszcze w kwestii kluczy w rejestrze - zakładam, że na końcówkach nie powinny znajdować się klucze xsyspass, natomiast na serwerze muszą, ponieważ jako para xsysuser/xsyspass stanowią o dostępie do bazy. Czy to jest jedyny ślad dostępu do bazy ? Pytanie wywodzi się stąd, że obecnie na serwerze mam ustawioną identyczną wartość klucza xsyspass, jak na laptopie (z którego lokalnie się dostaję do bazy), a mimo tego test połączenia do bazy na serwerze kończy się błędem. Zakładam, że nowa instalacja FB to rozwiąże.
______________
Odnośnie bezpieczeństwa - chodziło mi raczej o znalezienie "jakiegoś" wyjścia z mało komfortowej sytuacji, niż pokazywanie potencjalnych luk w systemie.

pozdrawiam
Yaho

[MK]

Odnośnie bezpieczeństwa - ja tylko napisałem jak jest, bo nie rzadko administrator myśli, że jak pozmieniał hasła, to ma bazę bezpieczną. Nic bardziej mylnego! Dlatego też, gdzie tylko mogę o tym piszę.
Co do xsyspass ? ciąg musi być wpisany w rejestrach jeśli jest inne niż masterkey hasło. Jeśli jest hasło standardowe, ciąg nie jest wymagalny ? choć możliwy.
Przy okazji, jeśli mówimy o wyczyszczeniu, to mówimy o usunięcia wpisu xsyspass i xsysuser a nie o pozostawieniu ich pustymi. Puste jest bee, należy po prostu wyciąć.
Xsyspass i xsysuser muszą być na tych stanowiskach wpisane, na których dokonujemy funkcji administracyjnej bazy danych, a więc np. upgrade bazy. Oczywiście dotyczy to FB, w przypadku Oracle umiemy aktualizować bazę danych na zwykłym użytkowniku, to FB wymaga użytkownika systemowego.
BDE nie ma nic do rzeczy.  Nie należy się nim w ogóle zajmować ? rozmawiamy tu o problemach niższego rzędu niż BDE się zajmuje. BDE można natomiast wykorzystać do weryfikacji, czy na dane hasło potrafimy się do bazy dostać. BDE administrator wymaga od nas wpisania hałas
"z palca", SOMED ma je wpisane, w formie oczywiście zakodowanej.
I na sam koniec, podpatrywanie wpisów zakodowanych ma sens tylko w tych samych instalacjach ? to tak na przyszłość.  Kluczem kodowania między innymi jest numer licencji ? dlatego, jeśli ktoś ma całkiem nowy plik licencyjny, z całkiem nowym numerem, to wpisy w rejestrach mu się mocno rozjadą.