Zum Inhalt springen
View in the app

A better way to browse. Learn more.

Fachinformatiker.de

A full-screen app on your home screen with push notifications, badges and more.

To install this app on iOS and iPadOS
  1. Tap the Share icon in Safari
  2. Scroll the menu and tap Add to Home Screen.
  3. Tap Add in the top-right corner.
To install this app on Android
  1. Tap the 3-dot menu (⋮) in the top-right corner of the browser.
  2. Tap Add to Home screen or Install app.
  3. Confirm by tapping Install.

Win2K: Anmeldefenster trotz Domäne

Empfohlene Antworten

Veröffentlicht

Moin!

Ich habe folgendes Problem bei einem Kunden:

Mehrere Win2KPro Clients hängen an einem Win2K server ein einer Domäne zusammen. Unser Programm wird auf allen CLients installiert. Die Firma, die sich um das Netz beim Kunden kümmert weigert sich die Datenbank für das Programm auf dem Server zu installieren. Darum ist die DB jetzt auf einem der Clients installiert.

Jetzt kommts:

Wenn jetzt ein Benutzer auf die DB zugreifen will, bekommt er das kleine Anmeldefensterchen, in dem er Namen und Passwort eingeben muss.

Aber warum? Eigentlich dürfte das doch nicht passieren, weil alle Rechner in der gleichen Domäne hängen! Oder wie kann ich das verhindern?

Danke im voraus für konstruktive Ideen!

Nun ja, da kenne ich Dein Programm zuwenig. Aber trotzdem mal eine Frage:

Wenn ihr die Datenbank auf einem Server installiert, wie läuft das dann? Muss sich der Benutzer da dann nicht authentifizieren? (Wie kann man dann feststellen, welcher User was gemacht hat???)

Wie läuft die Installation (zum Vergleich mit der Installation Deiner Problemstellung) normalerweise ab? Ich verstehe das jetzt so:

Normalinstallation: Datenbank auf Server, Programm auf den Clients

Jetztzustand: Datenbank auf einem bestimmten Client, Programm auf den Clients

oder hab ich was falsch verstanden? Musst schon etwas genauer werden.

Meine Idee ist eigentlich, dass die Anmeldung deshalb kommt, weil der Client auf dem die Datenbank liegt, die Anmeldedaten von der Domänenanmeldung nicht verfügbar hat. Der Domänenserver hingegen schon. Auf dem hat die Anmeldung ja bereits stattgefunden. greift die Datenbank auf diese Daten zurück, muss natürlich keine weitere Anmeldung stattfinden. Aber das ist nur so eine Idee...

  • Autor

Hi!

Also die Anmeldung an der Datenbank übernimmt automatisch das Programm.

Bei dem Anmeldebildschirm handelt es sich um den Windowsanmeldebildschirm. Ist der gleiche den man bekommt, wenn man mit einem Rechner auf einen Server in der Domäne zugreifen möchte, der Rechner aber nicht in der Domäne hängt.

Normalinstallation: Datenbank auf Server, Programm auf den Clients

Jetztzustand: Datenbank auf einem bestimmten Client, Programm auf den Clients

Ja, ganz genau.

Wegen genauer werden: 'Tschuldigung, dachte es (mach ich immer noch;) ) das es sich um ein reines Windowsproblem handelt.

Original geschrieben von Pointerman

Hi!

Also die Anmeldung an der Datenbank übernimmt automatisch das Programm.

Bei dem Anmeldebildschirm handelt es sich um den Windowsanmeldebildschirm. Ist der gleiche den man bekommt, wenn man mit einem Rechner auf einen Server in der Domäne zugreifen möchte, der Rechner aber nicht in der Domäne hängt.

Nun dann hast Du Dir die Frage bereits selbst beantwortet. Bei der Normalinstallation bekommt das Programm die Anmeldeinformationen über den Server auf dem der Client angemeldet ist und auf dem auch die Datenbank liegt. Nun ist die Datenbank jedoch nicht auf dem Server sondern auf einem xbeliebigen Client, dem diese Anmeldeinfos nicht vorliegen. Daher fragt die Datenbank hier vermutlich nochmal nach. Ich denke nicht, dass es sich um ein "Windows-Problem" handelt, sondern dass das eher ganz normal ist. Hast Du schon mal versucht, ob sich das Problem Eures Kunden bei Euch in der Firma rekonstruieren lässt?

  • Autor

Ja, habe ich schon ausprobiert und hier ist es das gleiche.

Mit "Problem" meinte ich auch nicht das es ein Bug ist, sondern eine Tatsache, die störend ist und aus dem Weg geräumt werden soll :D .

Danke soweit erstmal.

Wenn jemand doch noch irgendetwas finden sollte, ich bin immernoch interessiert!

Also ihr habt ein programm geschrieben und dei DB liegt auf einem Client ... soweit klar !!!!

Damit die User dadrauf zugreifen müssen ( normalerweise wenn die DB auf dem Server liegt ) müssen sie sich authentifizieren ( ich hasse dieses Wort )...

Was du machen bzw. testen kannst, ist :

Leg mal alle user die auf die DB zugreifen sollen in eine Gruppe auf dem Client ( welche Rechte die brauchen musst du entscheiden )

D.h. Du legst auf dem Cleint eine neue Gruppe an, und fügst da die Domänen benutzer die diese DB nutzen sollen rein !

Dann schaust du nach den berechtigungen die diese gruppe braucht bzw. haben soll und vóila ... eigentlich sollte das klappen !

Das ist das prinzip einer Arbeitsgruppe, da die User sich nciht mehr auf dem Server authentifizieren sondern an dem Client

In einer Arbeitsgruppe müssen alle user ( wenn sie über all zugreifen sollen ) auch an ALLEN Clients angelegt werden ! Da hier aber ALLE User nur auf den einen PC zugreifen, musst du auf dem "Quasi DB Server" diese User lokal anlegen und ihnen Rechet verpassen !

sollte eigentlich funktionieren, da die User sich ja sonst am AD bzw. am NT Server anmelden, wenn die aber nicht da ist, dann melden sie sich im Prinzip an einer Arbeitsgruppe an, und damit das funktioniert müssen die User mit den entsprechenden Passwörtern auf dem "Quasi Server" angelegt werden !

Original geschrieben von Shadow2k

sollte eigentlich funktionieren, da die User sich ja sonst am AD bzw. am NT Server anmelden, wenn die aber nicht da ist, dann melden sie sich im Prinzip an einer Arbeitsgruppe an, und damit das funktioniert müssen die User mit den entsprechenden Passwörtern auf dem "Quasi Server" angelegt werden !

Hallo,

bin ein wenig kritisch ob diese Lösung denn auch funktioniert (aber wer weiss),

ihr setzt vorraus, das eine Anwendung nur ordentlich mit der durchgereichten Authentifizierung funktioniert, wenn sie auf einem Domänencontroller läuft und nicht auf einem einfachen W2K - Client.

Aufgrund dieser Tatsache dürften jegliche Anwendungen auch nicht auf Member-Servern funktionieren (egal ob NT4 oder 2000), da diese Member Server auch keine Anmeldung bereitstellen.

Dies ist jedoch falsch.

Als simples Gegenbeispiel kann man einen freigegeben Drucker auf einem W2k Client nehmen (in einer ADS), wenn ich mich mit meinem PC darauf verbinde (und die entsprechenden ACLs gesetzt sind), kann ich diese Freigabe nutzen ohne mich erneut authentifizieren zu müssen, dies müsste laut eurer Theorie auch nicht funktionieren. (Da der Client keine Anmeldedaten vorhält).

Eine Lösung weiss ich aber selbst nicht,

ich würde auf einen Fehler in der Anwendung tippen.

Gruß

Terran Marine

Original geschrieben von Terran Marine

Als simples Gegenbeispiel kann man einen freigegeben Drucker auf einem W2k Client nehmen (in einer ADS), wenn ich mich mit meinem PC darauf verbinde (und die entsprechenden ACLs gesetzt sind), kann ich diese Freigabe nutzen ohne mich erneut authentifizieren zu müssen, dies müsste laut eurer Theorie auch nicht funktionieren. (Da der Client keine Anmeldedaten vorhält).

Genau hier würde ich ansetzen:

Mach mal spaßeshalber am 2k Client wo die DB drauf laeuft eine Druckerfreigabe und eien Verzeichnisfreigabe und schau nach, ob du diese ohne das Anmeldefenster erreichen kannst. Falls dort auch das Anmeldefenster auftritt wuerde ich mal die Computerkonten aus der Domaene loeschen und diese neu in die Domaene bringen. Nutzt ihr eigentlich normale Domaenen-Accounts zum Anmelden an den PCs oder meldet ihr euch evtl. lokal an diesen an? Ist eien bloede Frage, muss aber mal gestellt werden ;)

Gruss, 2-frozen

Archiv

Dieses Thema wurde archiviert und kann nicht mehr beantwortet werden.

Configure browser push notifications

Chrome (Android)
  1. Tap the lock icon next to the address bar.
  2. Tap Permissions → Notifications.
  3. Adjust your preference.
Chrome (Desktop)
  1. Click the padlock icon in the address bar.
  2. Select Site settings.
  3. Find Notifications and adjust your preference.