Uitloggen na eerste login Network-share?

[Dubbeleb]

Hallo!

Ik heb een probleem met de verschafte toegang naar een network-share. De situatie is als volgt:

Ik heb een nas van Synology met gebruikersaccount:

user: X
password: Y

Dit account heeft géén admin rechten. De home folder wil ik als schijf 'mounten' zodat deze makkelijk toegankelijk is via mijn computer (elke gebruiker heeft zijn eigen home folder, deze folders zijn 'shared', dit heb ik in moeten stellen via een admin account in het configuratiescherm van de nas).

Dit gaat allemaal prima. Ik kies een schijfletter (H:) en de map via het netwerk: \\192.168.x.x\home. Als opties vink ik aan:

• opnieuw verbinding maken bij aanmelden
• verbinding maken met andere referenties

Vervolgens log ik in met username X en password Y en ik krijg toegang tot mijn gegevens. Tot zover gaat alles zoals je wilt dat het gaat.

Nu zijn er meerdere gebruikers die toegang willen tot hun persoonlijke home-folder op de nas. Helaas kan ik nergens aangeven dat ik met het huidig ingelogde account wil uitloggen. Alleen als ik de verbinding met de netwerkschijf verbreek (ofwel de netwerkschijf verwijder uit 'mijn computer') en vervolgens weer opnieuw mount (waarbij weer dezelfde opties worden gekozen) krijg ik weer (maar alléén de eerste keer) de mogelijkheid om in te loggen met een ander account.

In het kader van privacy is dit niet heel handig en ik kan me niet voorstellen dat hier geen easy solution voor bestaat.

Uiteraard heb ik op internet gezocht naar oplossingen (na 1,5 dag nu hoofdpijn van) maar dit blijkt al zo te werken sinds 2005 (!!) als ik de diverse artikelen nalees op internet. De oplossingen die worden voorgedragen:

• Via Windows-referenties > inloggegevens verwijderen
• Via cmd > net use * /delete
• Via Run > rundll32.exe keymgr.dll, KRShowKeyMgr > inloggegevens verwijderen

Echter is dit niet voor de 'simpele' computergebruiker weggelegd en lijkt me dit enorm omslachtig om (ook als ervaren gebruiker) elke keer zo om te moeten switchen...

Wie van jullie heeft de verlossende oplossing? Of een beter alternatief?

Dank voor jullie tijd!

[johnkeates]

Ik neem aan dat je met Windows werkt? Want dan heb je inderdaad dit probleem, niks aan te doen. Met macOS en Linux werkt het anders, en kan je wel gewoon inloggen/uitloggen naar wens en ook meerdere sessies tegelijk gebruiken.

[MAX3400]

WAT ben je aan het doen en waar?

Nu zijn er meerdere gebruikers die toegang willen tot hun persoonlijke home-folder op de nas. Helaas kan ik nergens aangeven dat ik met het huidig ingelogde account wil uitloggen

Alleen hier al lees ik meerdere tegenstrijdigheden. Elke user zou een apart account moeten hebben. En daarmee kan je dan apart inloggen op de PC en "dus" kan iedereen zijn eigen H-drivemapping aanmaken. Heb je dus niks van doen met spullen weghalen uit keymgr etc.

Ga eerst eens vertellen: is het 1 machine of zijn het 10 random machines? Welk OS staat erop? Zijn het local / domain / universal users? Heb je "enige vorm" van LDAP-achtige zaken ingericht?

[belrpr]

Hij probeert op 1 computer vanuit dezelfde account te verbinden naar meerdere home drives met verschillende gebruikers maar dit gaat niet

Oplossing is aparte computer accounts. Ofwel 1 generieke gebruiker maken op de baas die rechten heeft op alle home drives. Nadeel geen afgescheiden rechten.

[MAX3400]

belrpr schreef op zaterdag 2 maart 2019 @ 18:00:
Hij probeert op 1 computer vanuit dezelfde account te verbinden naar meerdere home drives met verschillende gebruikers maar dit gaat niet

Oplossing is aparte computer accounts. Ofwel 1 generieke gebruiker maken op de baas die rechten heeft op alle home drives. Nadeel geen afgescheiden rechten.

Oplossing is: aparte user accounts maken op de machine(s) die dus hun eigen share mogen benaderen op de SMB-share.

Het lastige is; @Dubbeleb geeft te weinig info want een mapping naar \\nas\home is je root-share en als er maar 1 account is, zoals in de topicstart genoemd, dan heeft dat account "altijd" dezelfde permissies / shares te zien.

[Dubbeleb]

Sorry voor te weinig info!

Ik werk inderdaad met Windows 10 Pro. Het gaat om 1 computer met 1 Windows-account (wat automatisch inlogt).

Ik heb op de nas meerdere accounts en elk account heeft zn eigen share. Nu heb ik ook een account aangemaakt voor m'n Raspberry Pi.

De Raspberry Pi heb ik gelinkt naar zijn homefolder op de nas, dit werkt ideaal aangezien ik (zonder dat de Pi aan hoeft te staan) gegevens op het nas-account van de Pi kan zetten en deze de volgende keer automatisch worden ingelezen in de Pï.

Het is mijns inziens dan te omslachtig om voor de Pi op de computer een account aan te maken om daar dan zijn eigen toegang te hebben tot zijn home-folder. Dan ben ik meer aan het wisselen van Windows-accounts dan dat ik efficient aan het werk ben.

Ik ben er bang voor dat @belrpr en @johnkeates gelijk hebben dat dit niet versimpeld kan zoals op een Mac

[Cpt.Morgan]

Je kunt toch gewoon de account waar jij normaal onder werkt ook rechten geven op de home directory van de Raspberry Pi (in DSM op je Synology)? Dan kun je er ook vanuit je normale account bij, zonder gelijk admin rechten te gebruiken en zonder van account te wisselen?

[ Voor 55% gewijzigd door Cpt.Morgan op 02-03-2019 20:42 ]

[MAX3400]

Ik snap het probleem niet meer? Zit even te testen:

net use h: \\nas\dir /user:a /password:a
-> ik zie op mijn NAS in Resource Monitor dat user a verbonden is met dir
net use h: /delete
net use h: \\nas\dir /user:b /password:b
-> ik zie op mijn NAS in Resource Monitor dat user b verbonden is met dir

En dat allemaal terwijl ik met user x op mijn laptop ingelogd ben zonder drive-mapping naar NAS.

Iets zegt met dat je dus ook met Remove-PSDrive, Get-Credential en New-PSDrive (en dus voorzien van de credential-variabelen), een vergelijkbaar iets kan bouwen waardoor je dus niet "elke gebruiker" je stappenplan uit de startpost hoeft te laten uitvoeren.

[ Voor 32% gewijzigd door MAX3400 op 02-03-2019 18:25 ]

[Masimo]

Je hebt met het admin account van de NAS toch toegang tot alle user shares in de homes folder? Als je daarmee inlogt kun je via Windows explorer alle (user) mappen benaderen. Alle andere users, zoals bijv. je RPi of anderen die via hun eigen machine inloggen, kunnen hun eigen folder in de Homes map naar eigen behoefte mounten met hun eigen username /password. En die gebruikers zien ook alleen maar wat jij wilt dat ze zien. Kwestie van rechten instellen. Jij als admin kan achter de schermen overal in.

[ Voor 10% gewijzigd door Masimo op 02-03-2019 23:49 ]

[Brahiewahiewa]

MAX3400 schreef op zaterdag 2 maart 2019 @ 18:23:
Ik snap het probleem niet meer?...

Het probleem zit hierin dat Microsoft anno 2019 nog steeds maar één set user credentials ondersteunt bij connecties naar een netBIOS naam. Als je een tweede connectie maakt met andere credentials van krijg je

System error 1219 has occurred.

Multiple connections to a server or shared resource by the same user, 
using more than one user name, are not allowed. 
Disconnect all previous connections to the server or shared resource and try again.

Dit geldt voor alle connecties. Dus bijv. ook als je een ODBC connectie hebt naar een SQL server, dan kun je geen drive mappen naar diezelfde server met andere credentials.
De enige workaround die je hebt is het veranderen van de netBIOS naam. Dus als je een connectie hebt naar \\server, dan kun je een tweede connectie maken naar \\server.fqdn en eventueel een derde naar \\<ip-adres van server>. Als je nog meer connecties nodig hebt moet je je hosts file (of je lmhosts file of je DNS) frauderen.

Dat ze daar in 1985 niet over nagedacht hebben is ze nog wel te vergeven, maar ze hebben ondertussen ruim 30 jaar de tijd gehad om 't te fixen, maar het nog steeds niet gedaan

[MAX3400]

Brahiewahiewa schreef op zondag 3 maart 2019 @ 10:35:
[...]

Het probleem zit hierin dat Microsoft anno 2019 nog steeds maar één set user credentials ondersteunt bij connecties naar een netBIOS naam.

Dat is echt vreemd; het stappenplannetje uit mijn vorige post werkt hier gewoon. Ik moet er wel bij zeggen dat ik inderdaad verbind op IP en niet op NetBIOS.

Maar je kan inderdaad niet een drive H mappen als user A en daarna een drive G mappen als user B; het is een beetje catch-22 want het feit alleen al dat er een machine staat waar maar 1 account lokaal op staat en "daar werkt iedereen maar op" is sowieso niet handig. 1 persoon hoeft maar iets verkeerd / doms te doen en de rest van de personen kan data niet meer zien (of juist data zien waar ze niets mee te maken mogen hebben).

In het kader van privacy is dit niet heel handig

@Dubbeleb als privacy > technologie; gebruik niet 1 PC met een autologon-account.

[waal70]

Bij Synology is de /home share gelinkt aan de gebruiker. Als ik userA ben, dan is /home eigenlijk /homes/userA. Inloggend als userB wijst /home dan dus maar /homes/userB.

Ik denk dat je voor jouw case dus /home moet vergeten:
Beter kun je linken met /homes/userA en /homes/userB en daar met rechtentoewijzing op je Synology mee zorgen dat bijvoorbeeld userA allebei de mappen mag zien.
Of, als je in Windows inlogt met userA, daar de /home mapping voor gebruiken en dan als tweede share /homes/userB.

[downtime]

Brahiewahiewa schreef op zondag 3 maart 2019 @ 10:35:
[...]

Het probleem zit hierin dat Microsoft anno 2019 nog steeds maar één set user credentials ondersteunt bij connecties naar een netBIOS naam. Als je een tweede connectie maakt met andere credentials van krijg je [cmd]System error 1219 has occurred.

[...]

Dat ze daar in 1985 niet over nagedacht hebben is ze nog wel te vergeven, maar ze hebben ondertussen ruim 30 jaar de tijd gehad om 't te fixen, maar het nog steeds niet gedaan

Wat valt er te fixen? Als je 30 seconden nadenkt over accounts en permissies is dit nooit een echt probleem. Ik kom dit probleem op m’n werk soms tegen en het is eigenlijk altijd gevolg van luiheid en/of onkunde omdat mensen (in mijn geval vaak developers) de autorisaties op shares niet goed inregelen en dan maar meerdere accounts naast elkaar gaan gebruiken om toch overal bij te kunnen.

[DukeBox]

M.b.t. het uitloggen van huidige credentials, dat kan door net use /d van de shares en cmdkey /d van de gebruikte credentials.
Meerdere shares onder verschillende accounts kan zoals eerder genoemd met een dns alias al los je het probleem dan aan de verkeerde kant op.

[ Voor 10% gewijzigd door DukeBox op 03-03-2019 11:34 ]

[Croga]

downtime schreef op zondag 3 maart 2019 @ 11:22:
Wat valt er te fixen? Als je 30 seconden nadenkt over accounts en permissies is dit nooit een echt probleem. Ik kom dit probleem op m’n werk soms tegen en het is eigenlijk altijd gevolg van luiheid en/of onkunde omdat mensen (in mijn geval vaak developers) de autorisaties op shares niet goed inregelen en dan maar meerdere accounts naast elkaar gaan gebruiken om toch overal bij te kunnen.

^^ dit! Zoveel dit!!

De use case is dat één gebruiker schrijf rechten zou moeten hebben op de home folder van een andere gebruiker.
De oplossing die we nu proberen is die ene gebruiker in te laten loggen met de credentials van de andere gebruiker.

In iedere professionele omgeving zou deze persoon een officiële waarschuwing krijgen. Je logt niet in met de credentials van een andere gebruiker! De mogelijkheid zou niet eens mogen bestaan aangezien je het wachtwoord niet eens zou moeten kunnen weten!

Dus kijk nu eens naar een serieuze oplossing. Één die logisch is en niet tegen de normale beveiligingsregels in gaat. In dat geval geef je die eerste gebruiker gewoon schrijfrechten op de folder van die andere gebruiker en je probleem is opgelost. Of nog veel beter: Je gebruikt hier niet de home folder voor maar gewoon een gezamelijke share! (dat daar op de Synology geen verschil tussen zit is iets wat we hier gerust even kunnen negeren)

Ofwel @Verwijderd zet een aparte share op, geef daar jezelf rechten op (en iedereen die die rechten ook nodig heeft), verwijs de Pi naar die folder en je hele probleem is *NETJES* opgelost.

Iedereen heeft jaren geklaagd over de lekke security van Windows. Nou heeft Microsoft het eindelijk fatsoenlijk voor elkaar en klagen we allemaal dat ze het te goed beveiligd hebben......

[Brahiewahiewa]

Croga schreef op zondag 3 maart 2019 @ 11:34:
[...]
Iedereen heeft jaren geklaagd over de lekke security van Windows. Nou heeft Microsoft het eindelijk fatsoenlijk voor elkaar en klagen we allemaal dat ze het te goed beveiligd hebben......

Nee! Microsoft heeft het niet fatsoenlijk voor elkaar. Volgens hun eigen regels (het secure computing initiative uit het begin van dit millennium) mag je niet datavelden gebruiken om gegevens te indexeren. Dat doen ze in dit geval wel en dat is de oorzaak van het hele probleem.
Ze indexeren de netwerk connecties op basis van de netBIOS naam en dan krijg je inderdaad een probleem als je twee verschillende credential sets gebruikt. Een fatsoenlijk operating system zou z'n netwerk connecties indexeren op basis van een GUID en d'r een label aan hangen met de netBIOS naam; problem solved

En het is natuurlijk helemaal van de gekke om vervolgens te gaan eisen dat je je beveiligingsmodel moet gaan aanpassen aan dit soort broddelwerk
[/rant]

[To_Tall]

Ik denk dat het wel simpel kan. Via een mooi powershell script die je aanroept. Deze maakt dan de share vraagt om een username en wachtwoord.

En ben je klaar dan sluit je de netwerk connectie ook met een uitlog script.

[Brahiewahiewa]

To_Tall schreef op zondag 3 maart 2019 @ 22:19:
Ik denk dat het wel simpel kan. Via een mooi powershell script die je aanroept. Deze maakt dan de share vraagt om een username en wachtwoord.

En ben je klaar dan sluit je de netwerk connectie ook met een uitlog script.

Nou, het kan dus nog simpeler: je maakt onder je eigen user credentials een connectie naar \\<netBIOS-naam-van-NAS>\<jouw-home-folder> en je maakt een connectie als admin naar \\<ip-adres-van-NAS>\<root-van-het-file-system>
Die twee connecties kunnen keurig naast elkaar bestaan zonder dat Windows er over mekkert

[Dubbeleb]

Bedankt allemaal voor het meedenken! Ik had gehoopt op een simpele oplossing maar helaas blijkt wat ik wil gewoon niet te kunnen.

Jammer maar helaas! Fijne avond allemaal