Installationsprobleme unter Windows 8 trotz Admin-Account

[gonzo]

Hallo zusammen,

ich bekomme unter Windows 8 immer folgende Mitteilung, dass Administrationsrechte erforderlich sind.

Das Problem ist nur, mein Domänen-Account ist in der lokalen Administratoren-Gruppe. Andere Programme zu installieren, ist kein Thema. Nur der TS-Doctor will nicht. Ignoriert man  die Meldung, kommt beim ersten Starten der Hinweis, der TS-Doctor ist nicht richtig installiert.

Ein Test in einer VM unter Windows 8 mit einem lokalen Account, der Administrator ist, hat keine Probleme.

Mir ist nicht ganz klar, welche Rechte fragt das Installationsprogramm denn ab, reicht eine Mitgliedschaft in der lokalen Administratoren-Gruppe nicht aus?

Viele Grüße,
Gonzo

[Cypheros]

Der TS-Doctor läßt sich nur über einen lokalen Admin-Account installieren, da bei der Installation Daten nach HKEY_Local_Machine geschrieben werden. Bei Domain-Account wird dies von Windows offenbar anders gehandhabt. warum ist mir nicht bekannt. Vielleicht weiß Mam ja eine Antwort, der kennt sich im Domain-Umfeld aus.

[Mam]

Also so beim ersten Lesen finde ich da auch keinen Fehler.
Solange der Domänen-Account in der lokalen Admingruppe ist, sollte alles wie gewohnt fluppen.

Allerdings gibt es bei Windows8 einige böse Hakler und Fehler im Zusammenspiel mit "alten" (2003/2008/2008R2) Domänencontrollern. Da kommen schon mal unter Umständen völlig irrsinnige Berechtigungen rüber, die zu seehr merkwürdigen (und manchmal nicht reproduzierbaren) Fehlverhalten führen.

Probier mal Folgendes (jaja, liest sich und klingt auch absolut unsinnig, aber funktioniert manchmal trotzdem bei Windows :

* Boote die W8 Maschine
* warte 2 Min, NICHT ANMELDEN!!!
* Fahre die Kiste wieder runter, bzw, mach gleich Neustart
* wieder 2 Min lang NICHT ANMELDEN
* nun langsam doch mal endlich anmelden
* hoffen :-)))

Es scheint, dass W8 dermassen auf Speed beim Booten getrimmt wurde, dass wichtige Anmeldeinformationen im LAN nicht abgewartet werden. Dadurch hat manchmal die Maschine selber, manchmal der Benutzer, nicht alle Rechte, die ihr/ihm zustehen. Ist wirklich nervig (und sorgte letztendlich dazu, dass ich hier alle W8 Kisten gebügelt habe und eine Neuinstallation nicht mehr erlaubt ist) und wird mit W8.1 noch deutlich schlimmer.

Merke: Du sollst keine eigenen Server mehr betreiben, Du sollst Dir gefälligst die Cloud mieten!

(ob 2012 Server funktionieren weis ich nicht, meine Nerven haben nicht ausgereicht einen solchen Test anzuberaumen. Windows Domänen (+Exchange Server) sind zu fragil zum Spielen...)

[gonzo]

Hallo zusammen,

vielen Dank für die Antworten. Kann leider erst ab Donnerstag testen.

Melde mich dann.

Grüße,
Gonzo

[gonzo]

Hallo zusammen,
leider hilft die Vorgehensweise von Mam nicht. Wäre auch nicht logisch, da ich nur den TS-Doctor nicht installieren kann. Habe das mal ausgetestet. TS-Doctor bringt den beschriebenen Fehler, eine Installation von Keypass nicht. Wenn ich die TS-Doctor-Installation (wie auch bei Keypass) starte, kommt auch die UAC-Warnung, d.h. eine Anforderung höherer Rechte findet statt.

Daher meine Frage an Cypheros, was prüfst Du den genau in HKLM ab, um zu entscheiden, dass die Installation nicht im  Admin-Umfeld ausgeführt wird? Ich hatte mal versucht, dass mit ProcessMon rauszubekommen, allerdings glaube ich, die Installationsroutine prüft ein solches Tool vorher ab, denn da kommt eine andere Fehlermeldung.

Viele Grüße,
Gonzo

[Mam]

Schade 

Dann hast Du jetzt echt die A§$@karte gezogen, denn nun besteht so die 93,6%tige Wahrscheinlichkeit, dass Du Dir ein Eigentor über die Gruppenrichtlinien eingefangen hast.

Viel helfen kann man Dir da nicht mehr. Ich kann Dir nur glaubhaft versichern, dass der Doc sich einwandfrei installieren und betreiben lässt in der Domänenumgebung mit normalen Domänenbenutzer (+lokalen Adminrechten).
Da hilft dann wohl nur die mühselige Methode:

* nächste Richtlinie deaktivieren , "gpupdate /force", neu probieren
* repeat until the cows come home or you run out of policies...

Sobald Du die "böse" Richtlinie gefunden hast, reingucken und bei jeder Einstellung raten, ob sie es sein könnte...

Nächstes Jahr das Ergebnis hier posten 

[Cypheros]

Daher meine Frage an Cypheros, was prüfst Du den genau in HKLM ab, um zu entscheiden, dass die Installation nicht im  Admin-Umfeld ausgeführt wird? Ich hatte mal versucht, dass mit ProcessMon rauszubekommen, allerdings glaube ich, die Installationsroutine prüft ein solches Tool vorher ab, denn da kommt eine andere Fehlermeldung.

Debuggen ist kein gute Idee, damit machst Du es nur schlimmer, da der Doc dann davon ausgeht geknackt zu werden und sich "anders" verhält.

Hier der abgekürzte Code für die Erkennung des Admins:

Code Auswählen Erweitern

OpenThreadToken(GetCurrentThread, TOKEN_QUERY, True, hAccessToken);
OpenProcessToken(GetCurrentProcess, TOKEN_QUERY, hAccessToken);
GetTokenInformation(hAccessToken, TokenGroups, ptgGroups, 1024, dwInfoBufferSize);
AllocateAndInitializeSid(SECURITY_NT_AUTHORITY, 2, SECURITY_BUILTIN_DOMAIN_RID, DOMAIN_ALIAS_RID_ADMINS, 0, 0, 0, 0, 0, 0, psidAdministrators);
if EqualSid(psidAdministrators, ptgGroups.Groups[x].Sid) then
  isAdmin := True;

Das Problem liegt meistens beim Zugriff auf HKEY_Local_Machine, da die Admin-Rechte eines lokalen Users nicht mit den Admin-Rechten eines Domain-User übereinstimmen auch wenn der Domain-User zur Admin-Gruppe gehört.

Also Lokaler_Admin(Lokal) <> Lokaler_Admin(Domain), warum weiß nur Microsoft.

[Mam]

Code Auswählen Erweitern

AllocateAndInitializeSid(SECURITY_NT_AUTHORITY, 2, SECURITY_BUILTIN_DOMAIN_RID, DOMAIN_ALIAS_RID_ADMINS, 0, 0, 0, 0, 0, 0, psidAdministrators);

Seehr löblich, sehr sauber programmiert. 
Leider aber auch seeehr veraltet, seeehr gefääährlich und wahrscheinlich seeehr falsch 

So bis Windows 2000 mag das ja noch ok gewesen sein, aber für heutige Systeme solltest Du die Abfrage doch nochmal deutlich überarbeiten, oder, besser, total ersetzen.

Das Problem besteht darin, dass es nicht mehr "DEN" Admin, bzw. "DIE" Admingruppe gibt. Es gibt Domänen-admins, Organisations-Admins, Sicherungsoperatoren, Serveroperatoren usw...
Die dürfen alle etwas tun, und bis auf Domänen-Admins erfolgt KEIN Mapping auf die lokale Admingruppe.

Vielmehr muß man wirklich zu "testing by doing" ausweichen, sofern man nicht programmtechnisch verzweifeln möchte.
Zumal die Organisation noch eigene Gruppen definieren kann, deren Mitglieder "ein bisschen" Admins sind...

Also z.B einfach frech OpenKeyEx(HKEY_LOCAL_MACHINE,....,KEY_ALL_ACCESS,...); und hoffen, dass kein Fehler 5 (Permission denied) kommt.
Dadurch haben leider die Anwendungsprogrammierer den schwarzen Peter, denn Du musst alle Dinge testen, die Dein Programm benötigt. In einem halbwegs komplizierten Projekt fast unmöglich, weil man ja meist gar nicht weis, welche Dinge ein einfacher Framework Aufruf so alles lostritt.

Also Lokaler_Admin(Lokal) <> Lokaler_Admin(Domain), warum weiß nur Microsoft.

Nein, wissen andere auch 
Beispiel meines letzten Kunden:
gefordert: 4-Augen Prinzip
Sprich: es darf NIEMANDEN geben, der eine Aktion alleine und unbeobachtet durchführen kann.
Also gibt es keine lokalen Admin, keine DomänenAdmins, nur einen Organisationsadmin, der aber nur als Karteileiche im Safe ruht.
Dafür gibts dann neue Gruppen, denen speziell die erforderten Rechte zugewiesen werden. Und dank UAC wird dann trotzdem noch jedesmal wenn nötig, ein ANDERES Passwort abgefragt...
(echt ätzend unter solchen Bedingungen nur ne Maus zu tauschen oder nen Drucker zu installieren, aber der Kunde ist bekanntlich König).
Mit Windoof kannste sowas Krankes hinbiegen (falls es jemand lesen will, ich hab hier noch die knappe 900 Seiten Dokumentation welche Gruppen einzurichten sind, und welche Rechte sie haben müssen, für 400 Standorte wurden knappe 1000 neue Gruppen benötigt).

Ich hab mal in meinen alten Sourcen rumgesucht, fand dieses Schnipsel von 1996:

Code Auswählen Erweitern

// Create a security descriptor that allows only local Administrators
    //   to do anything with the pipe.  Since Domain administrators are
    //   normally also local Administrators, this will serve most needs

    /************************************************************************\
    *
    * Build SIDs of local Administrators and Power Users.  Note that the Power
    *   Users group is defined on Windows NT machines, but not on Advanced
    *   Server machines.  This means that we will on Advanced Server machines
    *   have a DACL that has an ACE (for Power Users) that will never be used
    *
    \************************************************************************/

    {
      SID_IDENTIFIER_AUTHORITY siaNtAuthority = SECURITY_NT_AUTHORITY;

      InitializeSid(        psidAdministrators, &siaNtAuthority,(BYTE) 2);
      InitializeSid(        psidPowerUsers,     &siaNtAuthority, (BYTE) 2);

      *(GetSidSubAuthority( psidAdministrators, 0 )) = SECURITY_BUILTIN_DOMAIN_RID;
      *(GetSidSubAuthority( psidPowerUsers,     0 )) = SECURITY_BUILTIN_DOMAIN_RID;

      *(GetSidSubAuthority( psidAdministrators, 1 )) = DOMAIN_ALIAS_RID_ADMINS;
      *(GetSidSubAuthority( psidPowerUsers,     1 )) = DOMAIN_ALIAS_RID_POWER_USERS;

    }

Unterschiede:
* Es werden auch "Hauptbenutzer" erkannt
* Es werden sowohl lokale, als auch Domänengruppen erkannt (es gibt eigentlich keine Domänen-Hauptbenutzer... eigentlich...)
* Im Kommentar wurde schon damals gesagt, dass hiermit NICHT ALLE ADMINS abgedeckt werden!!! (das war damals aber egal, da es um das Sperren von Laufwerken und USB Sticks usw ging, nach dem Motto "Admins ja, alle anderen: NO STICK!)

(für die nicht B/C affinen Programmhansels: es werden zwei Variablen "psidAdministrators" und "psidPowerUsers" mit jeweils einer Berechtigungsliste gefüllt, deren Inhalt lokale und Domänen-Admins beschreibt. Der Vergleich, ob man Admin ist, hat gegen BEIDE Listen zu erfolgen, nicht nur die eine, wie bei Cypheros (man kann natürlich auch eine Liste bauen mit ALLEN Einträgen, und nur einen Vergleich durchführen, aber hier gings darum Rechte zu setzen, nicht zu testen)

[gonzo]

Hallo zusammen,

vielen Dank für die Tipps. Leider bin ich derzeit viel unterwegs, daher kann ich nicht testen.

@Mam: Ja, auch ich glaube, dass irgendetwas mit den GPOs nicht stimmt. Zumal ich zugebe, der DC ist 2008R2 ohne irgendwelche Erweiterungen bzgl. Windows 8  . Und unter Windows 7 mit Domänenaccount hat auch alles funktioniert. An der neuen TS-Doctor-Version kann es auch nicht liegen, ich habe aus dem meinem Archiv ein paar alte Versionen rausgesucht, auch die lassen sich auch nicht installieren (und die liefen früher). Ich werde mal eine virtuelle Maschine aufsetzen und nach und nach probieren, ab wann der Fehler auftritt.

@Cypheros: Ich werde mal versuchen, den Code nachzuvollziehen und ebenfalls in den virtuellen Umgebungen testen (ich habe aber gefühlt vor 15 Jahren das letzte Mal ein Visual Studio "in der Hand gehabt", mal sehen, ob es noch funktioniert  )

Übergangsweise werde ich den TS-Doctor erstmal virtuell unter Windows 7 betreiben.

Daher meine Frage: Soll dieser Thread geschlossen werden und ich eröffne, sowie ich etwas rausgefunden habe, einen neue oder soll ich das hier ranhängen? Da können aber auch drei bis vier Wochen ins Land gehen

Nochmals vielen Dank Euch beiden...

Grüße,
Gonzo

[Mam]

@Mam: Ja, auch ich glaube, dass irgendetwas mit den GPOs nicht stimmt. Zumal ich zugebe, der DC ist 2008R2 ohne irgendwelche Erweiterungen bzgl. Windows 8  . Und unter Windows 7 mit Domänenaccount hat auch alles funktioniert. An der neuen TS-Doctor-Version

Was Du unbedingt tuen musst: Lad die 2012 (Windows8) ADMX Dateien in Deine alte Domäne. Es gibt da extra son Downloadlink bei Mikrosaft (den ich jetzt natürlich verloren habe :-) )
Such nach "Windows8-Server2012ADMX-RTM.msi".
Installier es entweder in Sysvol, oder auf einer lokalen Maschine, die Du zum Administrieren nutzt.

Hintergrund: Bei Win8 haben einige GPOs andere Bezeichnungen / Werte. Mit den 2008admx Dateien siehts Du sie entweder gar nicht, oder es fehlen Auswahlen in Listboxen. Damit suchst Du Dir echt den Kippa*#~sch ab :-(

Spar Dir die Qualen, installier die aktuellen und finde neue GPOs, die Du vorher gar nicht vermisst hattest 

Der neue Kram wirkt sich natürlich nur auf W8 aus, aber ohne die werden einige alte Einstellungen gar nicht mehr beachtet...

Und Du kannst die einzelnen GPOs ja für die W8 Kiste per ACL abschalten und gucken, bis es nicht mehr geht... (also ersma alle wech, dann einzeln ein... meistens isset ja eh DefaultDomain... :-) )

[gonzo]

Was Du unbedingt tuen musst: Lad die 2012 (Windows8) ADMX Dateien in Deine alte Domäne. Es gibt da extra son Downloadlink bei Mikrosaft (den ich jetzt natürlich verloren habe :-) )

ich habs schon runtergeladen, jetzt nur noch Zeit finden .... ist derzeit das größere Problem ....

[stahlo]

Hallo,

Ist es geplant dieses Problem in einer kommenden Version zu lösen?

Ich bin mit der Testversion sehr zufrieden und würde gerne die Vollversion kaufen, da ich aber nur einen Firmen Notebook mein eigen nennen kann, habe ich das Problem mit der Installation (getestet habe ich auf dem Notebook eines Freundes).
Bei mir läuft Win7 Pro 64 bit, mein User ist in der Lokalen Admin Gruppe und ich kann leider auch keinen lokalen User einrichten.

Es wäre super, wenn es bald eine Lösung gibt. Mit allen anderen Installationen habe ich keine Probleme.

Besten Dank

[Cypheros]

Der Hinweis auf die fehlenden Admin-Rechte ist ja möglicherweise nicht ganz korrekt, wie Mam ja erklärt hat. Wenn Du die Warnung ignorierst, wird der TS-Doctor mit den zur Verfügung stehenden Rechten installiert. Falls der TS-Doctor nach der Installation funktioniert, waren die Rechte doch ausreichend.

Schau mal nach ob bei der Installation unter Win7 x64 der Key "HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Cypheros\TSDoctor" angelegt wird.

[stahlo]

Wenn ich die Warnung ignoriere, dann wird die Installation scheinbar nicht bis zu ende ausgeführt.

Wenn ich das Programm starte bekomme ich die Meldung, "Unvollständige Installation der Trial Version" und danach eine Windows Fehlermeldung "Zugriffsverletzung bei Adresse 0050F269 in Modul 'TSDoctor.exe'. Lesen von Adresse 00000000"

Der Registry Schlüssel existiert mit 4 Werten: FP1, FP2, InstallDir und Language.

[Cypheros]

OK, das sieht schon mal nicht ganz so schlecht aus. Siehst Du unter dem Key "HKEY_CURRENT_USER\Software\Cypheros\TSDoctor" die Keys "Install", "Settings" und "Uninstall" ?

Mal versucht den TS-Doctor über rechte Maustaste "Als Administrator" zu starten.