[2003] TS sessie zonder taskbar en startmenu realiseren

[nwagenaar]

Op dit moment ben ik bezig om een single applicatie te laten draaien in een Terminal Server sessie en dat de sessie afgelogt wordt op moment dat het programma wordt afgebroken. No problem, dit werkt als een trein. Nu wil ik voor de volledigheid ook de taskbar en startmenu geheel laten verdwijnen zodat alleen de desbetreffende applicatie draait.

Via Google heb ik mogelijke situaties/oplossingen gevonden :

- Aanpassen registry setting zodat de taskbar/startmenu geheel niet verschijnt;
- Aanpassen "Don't run specified Windows applications" policy item en hier Explorer.exe in zetten;
- Aanpassen rechten op explorer.exe en de desbetreffende user/gebruiker Execute rechten ontnemen;
- Aanpassen startmenu en deze hiden/locken zodat men het niet ziet;
- Killen van explorer.exe via een script of een tool.

Optie 1 is a no go, ik wil namelijk alleen voor een specifieke applicatie en voor een select aantal gebruikers de taskbar/startmenu niet laten zien. De registry aanpassen is namelijk direct voor alle gebruikers. Optie 2 werkt gewoon niet, explorer.exe wordt gewoon uitgevoerd en de taskbar/startmenu komt gewoon tevoorschijn. Optie 3 werkt ook niet, het systeem krijgt een foutmelding waarna de sessie afgelogt wordt. Optie 4 werkt maar ziet er gewoon niet uit (de Taskbar is namelijk niet geheel verdwenen en de startmenu werkt gewoon).

Nu rest mij dus optie 5. Ik heb geprobeerd om de huidige login VBS script uit te breiden via een wshShell.Run waarbij het programma pskill (applicatie van Sys Internals) het proces explorer.exe van de gebruiker killed. Dit werkt, alleen wordt explorer.exe direct weer opgestart.

Nu is mijn vraag, zijn er mogelijk personen die een soort gelijke situatie hebben gehad en dus ook een mogelijke oplossing hebben voor dit probleem? Ik heb GoT alsmede ook Google (web & usenet) goed nagekeken, maar kwam niet echt iets zinnigs tegen.

[Verwijderd]

Misschien een combinatie van optie 2 en 5, lijkt mij namelijk explorer.exe word opgestart voordat de policy's actief worden. Als je dan zorgt dat hij gekilled word door middel van een script zal hij daarna niet meer op mogen starten logisch gezien.

Er staat me ook iets van bij dat je een alternatief kan laden voor explorer.exe (bijvoorbeeld de applicatie die gebruikt moet kunnen worden), ik weet dat microsoft zo hun examens beveiligd door middel van policy's, heb er zelf meerdere gedaan.


Maar ben nog nooit tegen het probleem aangelopen weliswaar ben ik wel benieuwd naar de oplossing

[nwagenaar]

Verwijderd schreef op maandag 10 april 2006 @ 21:50:
Misschien een combinatie van optie 2 en 5, lijkt mij namelijk explorer.exe word opgestart voordat de policy's actief worden. Als je dan zorgt dat hij gekilled word door middel van een script zal hij daarna niet meer op mogen starten logisch gezien.

Er staat me ook iets van bij dat je een alternatief kan laden voor explorer.exe (bijvoorbeeld de applicatie die gebruikt moet kunnen worden), ik weet dat microsoft zo hun examens beveiligd door middel van policy's, heb er zelf meerdere gedaan.

Maar ben nog nooit tegen het probleem aangelopen weliswaar ben ik wel benieuwd naar de oplossing

Je kan inderdaad de Shell waarde aanpassen bij de Winlogon onderdeel van de registry en deze laten toewijzen aan bijvoorbeeld de executable van de applicatie. Het probleem alleen is, is dat de desbetreffende applicatie ook een beheersonderdeel heeft en die zal alleen toegankelijk zijn voor bijvoorbeeld de applicatiebeheerder(s) ( autorisatie gebeurt op basis van ADS username/password ) en soms moet deze personen bestanden vervangen van de applicatie. Dit betekend dus dat ik voor elke normale user deze wijziging moet maken in de registry. Met 10 nog wel te doen maar daarna wordt het aanzienlijk moeilijker te behe(e)r(s)en =)

Ik denk daarom dat het proces explorer.exe kill voldoende is. Ik heb het getest vanuit de taskmanager, als ik deze kill dan heb je geen taskmanager/startmenu. Maar vanuit het VBS login script wordt explorer.exe weer opnieuw opgestart

[Verwijderd]

Misschien dat het met een batch bestand wel mogelijk is, die zal niet automatisch weer explorer.exe oproepen. Dit is wat je nodig hebt om het proces te killen:

taskkill /im explorer.exe

[Verwijderd]

Je kan per user aangeven welk programma moet starten bij inloggen op TS. Ze krijgen dan geen taskbar te zien en overige aanverwante zaken. Ze zie dan alleen de app en als ze die afsluiten wordt de sessie beeindigd.

[nwagenaar]

Verwijderd schreef op maandag 10 april 2006 @ 22:19:
Je kan per user aangeven welk programma moet starten bij inloggen op TS. Ze krijgen dan geen taskbar te zien en overige aanverwante zaken. Ze zie dan alleen de app en als ze die afsluiten wordt de sessie beeindigd.

En bedankt voor deze tip

Ik had dus over deze optie heen gekeken omdat ik alleen zat te neuzen in de sub-containers ( Client en Sessions) van de Terminal Services onderdeel van de gemaakte Group Policy. Voor de geintresseerden, deze optie zit in de Group Policy : User Configuration -> Administrative Templates -> Windows Components -> Terminal Services. Hieronder zit de optie "Start a program on connection", hieronder dien je dus de applicatie te defineren!

[elevator]

nwagenaar schreef op maandag 10 april 2006 @ 22:03:
Je kan inderdaad de Shell waarde aanpassen bij de Winlogon onderdeel van de registry en deze laten toewijzen aan bijvoorbeeld de executable van de applicatie. Het probleem alleen is, is dat de desbetreffende applicatie ook een beheersonderdeel heeft en die zal alleen toegankelijk zijn voor bijvoorbeeld de applicatiebeheerder(s)

Hoewel de oplossing die je nu gebruikt (opgeven in de user settings van een account) de netste is moet ik dit nog even corrigeren. Je hebt er inderdaad een "globaal" onder HKLM, maar in de HKCU heb je een zelfde soort key op dezelfde plek die per user is

[Question Mark]

elevator schreef op maandag 10 april 2006 @ 23:28:
[...]
Hoewel de oplossing die je nu gebruikt (opgeven in de user settings van een account) de netste is moet ik dit nog even corrigeren. Je hebt er inderdaad een "globaal" onder HKLM, maar in de HKCU heb je een zelfde soort key op dezelfde plek die per user is

Een Terminal Server gebruikt toch alleen voor connecties naar de console HKCU. Normale TS usersessies worden toch gedraaid vanuit HKU\usersid\

Each time a user logs on to a Terminal Server, his or her own subfolder (technically called a “subtree”) is added to the HKU hive. If you have two users logged onto a server then you will see two SIDs listed under the HKU hive and each user’s unique settings stored in the registry structure under his SID. Fifty users logged in at the same time will appear as fifty SID folders listed in the HKU hive.

bron: The Windows Registry in Terminal Server Environments

[ Voor 8% gewijzigd door Question Mark op 11-04-2006 12:21 ]

[elevator]

Question Mark schreef op dinsdag 11 april 2006 @ 12:19:
Een Terminal Server gebruikt toch alleen voor connecties naar de console HKCU.

Nee, een HKCU is user specifiek, elke ingelogde user ziet dus een andere HKCU (wat feitelijk gewoon een symbolic link is naar de HKEY_USERS\{sid}

Normale TS usersessies worden toch gedraaid vanuit HKU\usersid\

Ook ja Als je ingelogged bent op de console is jouw HKCU niet meer dan een link naar HKEY_USERS\{sid} - net zoals HKEY_CLASSES_ROOT een symbolic link is naar HKEY_LOCAL_MACHINE\SOFTWARE\Classes

[Question Mark]

Ok, maar als ik dan via de registry aanpassingen aan het HKCU gedeelte van een user wil uitvoeren op een TS buiten de usersessie om (en ja, zulke scripts heb ik gemaakt en gedraaid), dan zal ik dit moeten targetten naar HKU\{sid}. De usersessie (en userapplicaties binnen deze sessie) weten dan niet beter dan dat het wijzigingen in HKCU zijn).

Dat is wat ik aan wou geven.

Doe ik een wijziging binnen de sessie voor HKCU, dan kan ik deze rechtstreeks targetten naar HKCU. Da's nieuw voor mij. Had me achteraf ook aardig wat scripting-time bespaard

[ Voor 20% gewijzigd door Question Mark op 11-04-2006 14:22 ]

[elevator]

Question Mark schreef op dinsdag 11 april 2006 @ 14:16:
Ok, maar als ik dan via de registry aanpassingen aan het HKCU gedeelte van een user wil uitvoeren op een TS buiten de usersessie om (en ja, zulke scripts heb ik gemaakt en gedraaid), dan zal ik dit moeten targetten naar HKU\{sid}.

Dat zal je altijd moeten aangezien de HKCU altijd verwijst naar de registry van de user waarmee je aanlogged. Als je dus bv. met psexec een batchfile start zal die de HKCU bevatten van de .DEFAULT of logged in credentials (even geen zin om te testen) user omdat psexec als die user start

[Question Mark]

elevator schreef op dinsdag 11 april 2006 @ 14:35:
[...]

Dat zal je altijd moeten aangezien de HKCU altijd verwijst naar de registry van de user waarmee je aanlogged. Als je dus bv. met psexec een batchfile start zal die de HKCU bevatten van de .DEFAULT of logged in credentials (even geen zin om te testen) user omdat psexec als die user start

Binnen de sessie kun je het script natuurlijk in de Startup folder van de user gooien. User heeft toch wel rechten om zijn HKCU te mogen editten. Overigens heb ik niet getest om rechtstreeks HKCU te targetten. Ik target altijd HKU\{sid}.

Nadeel is dat je eerst met user2sid in een For statement de usersid moet afvangen.

[elevator]

Question Mark schreef op dinsdag 11 april 2006 @ 15:07:
Ik target altijd HKU\{sid}.

Nadeel is dat je eerst met user2sid in een For statement de usersid moet afvangen.

Dat is inderdaad nodeloos complex - je hebt die symbolic links niet voor niets Ik heb nog nooit iets aangepast rechtstreeks in HKEY_USERS op de .DEFAULT na