Kan niet naar D$ verbinden vanaf een desktop buiten domein

[H8M3CuzUaintM3]

Een lokale desktop moet data plaatsen op de d drive van een andere server. We maken hiervoor gebruik van het een domain admin account om de connectie op te zetten naar de d drive in explorer.

\\IP address\d$ is werkt
\\hostname.domain\d$ werkt
\\hostname\c$ WERKT NIET Let op: vanaf een andere laptop in het domein werkt het wel!
\\hostname\d$ WERKT NIET Let op: vanaf een andere laptop in het domein werkt het wel!

Hiervoor krijgen we deze error:

\\hostname\d$ is not accessible. You might not have permission to use this network resource.
Contact the administrator of this serve rto find out if you have access permissions.

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.

Verbinden met \\hostname.domain\d$ naar een andere server met dezelfde domain credentials werkt naar behoren maar het verbinden naar de specifieke server werkt niet zonder .domain. Ik heb alle openstaande verbindingen naar de share al verbroken in mmc>shared folders.

[ Voor 33% gewijzigd door H8M3CuzUaintM3 op 30-09-2015 14:49 ]

[ElCondor]

Als je gewoon probeert \\hostname te doen, maakt hij dan wel connectie? Als dat al niet werkt, dan is er iets met DNS resolutie op de betreffende server. Probeer eens een ping HOSTNAME.

Hopelijk kom je daar verder mee.

[H8M3CuzUaintM3]

ElCondor schreef op woensdag 30 september 2015 @ 14:41:
Als je gewoon probeert \\hostname te doen, maakt hij dan wel connectie? Als dat al niet werkt, dan is er iets met DNS resolutie op de betreffende server. Probeer eens een ping HOSTNAME.

Hopelijk kom je daar verder mee.

\\hostname werkt wel en ik kan hem ook gewoon op naam pingen

[ Voor 5% gewijzigd door H8M3CuzUaintM3 op 30-09-2015 14:45 ]

[Hero of Time]

Als antwoorden in 't Nederlands prima is, doe dan ook moeite om je post in het Nederlands te maken. We doen niet zo heel moeilijk als posts in 't Engels is, maar je bent de taal prima machtig. Dit lijkt te veel op een copy/paste van een ander forum, al kan ik dat niet direct vinden.

Pas je je TS nog even aan?

[ElCondor]

Heb je resolutie naar IPv6 of IPv4? Heb je wellicht andere regels in je firewall voor IPv6 of IPv4 toegang tot shares? Wellicht een hostfile die parten speelt?

[H8M3CuzUaintM3]

ElCondor schreef op woensdag 30 september 2015 @ 14:48:
Heb je resolutie naar IPv6 of IPv4? Heb je wellicht andere regels in je firewall voor IPv6 of IPv4 toegang tot shares? Wellicht een hostfile die parten speelt?

Er wordt gebruik gemaakt van IPv4. Er staan geen regels in de firewall die dit proces zouden moeten blokkeren, het is een lokaal probleem op de desktop zelf aangezien \\hostename\d$ vanaf een andere laptop in het veld wel prima werkt en geen foutmelding krijgt... Tevens al geprobeerd om de desktop opnieuw te joinen in het domein, helaas zonder resultaat!

[ Voor 7% gewijzigd door H8M3CuzUaintM3 op 30-09-2015 14:52 ]

[@r!k]

Je hebt nog een connectie naar die share op die specifieke laptop staan. Daarom krijg je die melding, wellicht een mapping nog ergens aanwezig?

[H8M3CuzUaintM3]

@r!k schreef op woensdag 30 september 2015 @ 14:52:
Je hebt nog een connectie naar die share op die specifieke laptop staan. Daarom krijg je die melding, wellicht een mapping nog ergens aanwezig?

Net via net use even gekeken en er stond inderdaad nog een mapping naar de desbetreffende lokatie met \\ipadres\d$ deze heb ik verwijderd.

Helaas nog steeds geen mogelijkheid om vanuit explorer te connecten via \\hostname\d$ van die server met domain credentials nog steeds dezelfde foutmelding

[Hero of Time]

Ik heb de titel ook even vertaald.

Wat ik zo begrijp, is dat de server via IP en FQDN te bereiken is. Via de shortname niet. Omdat het bij systemen die wel in het domein hangen wel werkt, lijkt het erop dat de desktop waar je vanaf verbinding maakt geen degelijke domain search doet. Wat is de DNS server en de search domein van de betreffende desktop?

[_H_G_]

En misschien dat er nog ergens een WINS server draait?

[H8M3CuzUaintM3]

Hero of Time schreef op woensdag 30 september 2015 @ 14:58:
Ik heb de titel ook even vertaald.

Wat ik zo begrijp, is dat de server via IP en FQDN te bereiken is. Via de shortname niet. Omdat het bij systemen die wel in het domein hangen wel werkt, lijkt het erop dat de desktop waar je vanaf verbinding maakt geen degelijke domain search doet. Wat is de DNS server en de search domein van de betreffende desktop?

Dank!

De DNS servers zijn dezelfde primaire en secundaire als de desbetreffende server waarna we proberen te connecten vanaf die desktop

[ Voor 4% gewijzigd door H8M3CuzUaintM3 op 30-09-2015 15:00 ]

[H8M3CuzUaintM3]

_H_G_ schreef op woensdag 30 september 2015 @ 14:59:
En misschien dat er nog ergens een WINS server draait?

WINS wordt geen gebruik van gemaakt

[johnkeates]

Wat zie je als je een packet capture doet?

[donderdraak]

Ik heb het probleem ook eens gehad met een vm die dezelfde hostname kreeg met een ander macadres.
Als je kan pingen op ip dan is het een dns probleem.

Kun je de iptabel nakijken of router aan/uit zetten?
iplease weggooien en pc rebooten?
Zo'nee. Hoe staat de network discovery profile ingesteld?
Is er wel een lokaal wachtwoord ingesteld?
Zitten de machines allemaal op het gateway of zit er een desktop verbonden via wifi?

[H8M3CuzUaintM3]

donderdraak schreef op woensdag 30 september 2015 @ 15:08:
Ik heb het probleem ook eens gehad met een vm die dezelfde hostname kreeg met een ander macadres.
Als je kan pingen op ip dan is het een dns probleem.

Kun je de iptabel nakijken of router aan/uit zetten?
iplease weggooien en pc rebooten?
Zo'nee. Hoe staat de network discovery profile ingesteld?
Is er wel een lokaal wachtwoord ingesteld?
Zitten de machines allemaal op het gateway of zit er een desktop verbonden via wifi?

De desktop krijgt netjes een DHCP adres.
Desktop is reeds twee keer gereboot.
Network discovery staat aan.
De desktop is gewoon voorzien van de standaard image dus automatisch voorzien van een local admin account.
Desktop is gewoon verbonden via de wall outlet naar de switch, in het correcte VLAN.

[H8M3CuzUaintM3]

johnkeates schreef op woensdag 30 september 2015 @ 15:06:
Wat zie je als je een packet capture doet?

Kan je een tool noemen waarmee ik tevoorschijn kan halen wat je graag wilt zien?

[donderdraak]

supra_indo schreef op woensdag 30 september 2015 @ 15:13:
[...]


De desktop krijgt netjes een DHCP adres.
Desktop is reeds twee keer gereboot.
Network discovery staat aan.
De desktop is gewoon voorzien van de standaard image dus automatisch voorzien van een local admin account.
Desktop is gewoon verbonden via de wall outlet naar de switch, in het correcte VLAN.

kijk eens voor de grap of je pc nog wel in de juiste OU container staat!
doe daarna op de desbetreffende client waarop je geen rechten hebt
gpupdate /force
reboot

[ Voor 16% gewijzigd door donderdraak op 30-09-2015 15:23 . Reden: volgorde van advies aangepast ]

[H8M3CuzUaintM3]

donderdraak schreef op woensdag 30 september 2015 @ 15:19:
[...]


kijk eens voor de grap of je pc nog wel in de juiste OU container staat!
doe daarna op de desbetreffende client waarop je geen rechten hebt
gpupdate /force
reboot

Geen resultaat! Nog steeds dezelfde foutmelding...

[donderdraak]

supra_indo schreef op woensdag 30 september 2015 @ 15:26:
[...]


Geen resultaat! Nog steeds dezelfde foutmelding...

Ter verificatie zijn het allemaal dezelfde windows machines/images? En kun je wel lokaal inloggen met het lokale administrator account op die desktop waarop je die d$ niet kunt benaderen?

[Question Mark]

Wat is het precies probleem nog met het verbinden op FQDN? Dan werkt het toch? Dat is sowieso de nettere manier.

Voor de rest moet je voor datatransfers geen misbruik gaan maken van een Administrative Share, maar hiervoor even netjes een nieuwe share aan gaan maken.

[donderdraak]

supra_indo schreef op woensdag 30 september 2015 @ 14:19:

\\IP address\d$ is werkt
\\hostname.domain\d$ werkt
\\hostname\c$ WERKT NIET Let op: vanaf een andere laptop in het domein werkt het wel!
\\hostname\d$ WERKT NIET Let op: vanaf een andere laptop in het domein werkt het wel!

Je maakt overigens verbinding met een lokale host. Wat jij probeerde \\hostname.domain werkt daarom niet. Dat is een instelling omdat je laptop vermoedelijk niet is aangemeld op het domein? Dit heeft temaken met forward zones ingeregeld door dnsserver en daarom moet je .domein erachter zetten.

Laat ook even weten wat je besturingssysteem van client en server is dit ivm interne firewall settings en hulp bij referentie van de juiste GUI. Graag ook laten weten hoe je laptops in het domein gekoppeld zijn.

[ Voor 96% gewijzigd door donderdraak op 30-09-2015 15:49 ]

[Hero of Time]

supra_indo schreef op woensdag 30 september 2015 @ 15:00:
[...]

De DNS servers zijn dezelfde primaire en secundaire als de desbetreffende server waarna we proberen te connecten vanaf die desktop

En de search domain? Die kan je zien als je 'ipconfig /all' uitvoert. Als die leeg is, dan is 't op zich ook wel logsich dat je niet direct naar de server toe kan, die eist namelijk om via FQDN aangeroepen te worden. Domein clients sturen hun domein al mee, dus komt 't als FQDN bij de server. Als failsafe werkt op IP basis.

Om echt zeker te zijn dat het aan de server ligt en niet wat anders, wat krijg je terug bij een nslookup van de shortname en de fqdn?

[H8M3CuzUaintM3]

Question Mark schreef op woensdag 30 september 2015 @ 15:35:
Wat is het precies probleem nog met het verbinden op FQDN? Dan werkt het toch? Dat is sowieso de nettere manier.

Voor de rest moet je voor datatransfers geen misbruik gaan maken van een Administrative Share, maar hiervoor even netjes een nieuwe share aan gaan maken.

De desktop is express onder een bureau geplaatst op de ServiceDesk van een ServiceDesk medewerker, er is ook geen beeldscherm aangesloten dus misbruik wordt er zeker niet van gemaakt. Maar ik begrijp je logica!

[Question Mark]

Je misbruikt nu een share die puur bedoeld is voor administrative beheer.

Je moet al admin rechten hebben, wil je toegang tot tot een admin share krijgen. En Admin rechten uitdelen op een compleet systeem voor alleen het plaatsen van wat bestanden is niet echt een best practise.

Vandaar de term misbruik, dit moet je gewoon niet willen.

Edit:

Ik lees net in je topicstart dat je hier een Domain Admin voor gebruikt...

[ Voor 11% gewijzigd door Question Mark op 30-09-2015 16:05 ]

[H8M3CuzUaintM3]

Hero of Time schreef op woensdag 30 september 2015 @ 15:40:
[...]

En de search domain? Die kan je zien als je 'ipconfig /all' uitvoert. Als die leeg is, dan is 't op zich ook wel logsich dat je niet direct naar de server toe kan, die eist namelijk om via FQDN aangeroepen te worden. Domein clients sturen hun domein al mee, dus komt 't als FQDN bij de server. Als failsafe werkt op IP basis.

Om echt zeker te zijn dat het aan de server ligt en niet wat anders, wat krijg je terug bij een nslookup van de shortname en de fqdn?

Search domain? Bedoel je hiermee DNS Suffix? Die is wel leeg namelijk op de server... als je dit bedoeld hoe kan ik die vullen?

Server: AD server
Address: ip van de AD server

Name: server waar de d$ niet benaderd kan worden op \\hostname\d$
Address: ip van deze server

[H8M3CuzUaintM3]

Question Mark schreef op woensdag 30 september 2015 @ 16:05:
Je misbruikt nu een share die puur bedoeld is voor administrative beheer.

Je moet al admin rechten hebben, wil je toegang tot tot een admin share krijgen. En Admin rechten uitdelen op een compleet systeem voor alleen het plaatsen van wat bestanden is niet echt een best practise.

Vandaar de term misbruik, dit moet je gewoon niet willen.

Edit:

Ik lees net in je topicstart dat je hier een Domain Admin voor gebruikt...

Ik begrijp heel goed wat je bedoeld, dank voor je goede uitleg in ieder geval

[Question Mark]

Nogmaals... Gewoon verbinden op FQDN in plaats van hostname. Ik gok dat Kerberos nu niet toestaat om te verbinden op hostname. Daar zijn wel wat issue's mee vanaf niet trusted werkstations.

Even voor mijn beeldvorming: waarom is die desktop niet gewoon netjes lid van het domein? Dat ben je dit soort beheersellende kwijt namelijk.

[CH4OS]

supra_indo schreef op woensdag 30 september 2015 @ 16:01:
[...]


De desktop is express onder een bureau geplaatst op de ServiceDesk van een ServiceDesk medewerker, er is ook geen beeldscherm aangesloten dus misbruik wordt er zeker niet van gemaakt. Maar ik begrijp je logica!

Tja, middels RDP is een garantie dat zoiets niet gebeurd? Via FQDN kun je wel verbinden, dat is dan toch voldoende? Al is het onlogisch om een administrative share te gebruiken hiervoor, aangezien je dan aangemeld moet zijn als administrator. Nu weet ik niet wat er precies moet gebeuren, maar als je een normale share gebruikt, heb je ook wat meer security mogelijkheden.

En zoals gezegd, als je de machine in hetzelfde domein hangt, zijn alle problemen als sneeuw voor de zon verdwenen, is namelijk gewoon 'standaard' wat er gebeurd en eigenlijk is dat ook wel logisch. Als de PC binenn het domein wordt gezet, zul je zien dat beide mogelijkheden wel gaan werken.

[ Voor 44% gewijzigd door CH4OS op 30-09-2015 16:13 ]

[H8M3CuzUaintM3]

Question Mark schreef op woensdag 30 september 2015 @ 16:08:
Nogmaals... Gewoon verbinden op FQDN in plaats van hostname. Ik gok dat Kerberos nu niet toestaat om te verbinden op hostname. Daar zijn wel wat issue's mee vanaf niet trusted werkstations.

Even voor mijn beeldvorming: waarom is die desktop niet gewoon netjes lid van het domein? Dat ben je dit soort beheersellende kwijt namelijk.

De desktop is gewoon netjes lid van het domein hoor, ik heb nergens aangegeven dat dit niet het geval is. De desktop komt ook netjes terug in de DHCP.

Vreemde is gewoon vanaf een andere laptop werkt \\hostname\d$ wel, ik zou dan juist het probleem lokaal op de desktop zoeken.. maar herinstalleren is even echt geen optie! De gebruiker gaat nu de volledige FQDN gebruiken maar voor mij is dit nog geen oplossing...

[H8M3CuzUaintM3]

CptChaos schreef op woensdag 30 september 2015 @ 16:09:
[...]
Tja, middels RDP is een garantie dat zoiets niet gebeurd? Via FQDN kun je wel verbinden, dat is dan toch voldoende? Al is het onlogisch om een administrative share te gebruiken hiervoor, aangezien je dan aangemeld moet zijn als administrator. Nu weet ik niet wat er precies moet gebeuren, maar als je een normale share gebruikt, heb je ook wat meer security mogelijkheden.

En zoals gezegd, als je de machine in hetzelfde domein hangt, zijn alle problemen als sneeuw voor de zon verdwenen, is namelijk gewoon 'standaard' wat er gebeurd en eigenlijk is dat ook wel logisch. Als de PC binenn het domein wordt gezet, zul je zien dat beide mogelijkheden wel gaan werken.

Zoals eerder aangegeven, de desktop hangt netjes in het domein. De desktop is zelfs opnieuw in het domein gehangen maar de foutmelding blijft als ik de d$ van de server wil benaderen. Na het invoeren van de credentials (domain admin) krijg je de foutmelding...

[CH4OS]

supra_indo schreef op woensdag 30 september 2015 @ 16:25:
Zoals eerder aangegeven, de desktop hangt netjes in het domein. De desktop is zelfs opnieuw in het domein gehangen maar de foutmelding blijft als ik de d$ van de server wil benaderen. Na het invoeren van de credentials (domain admin) krijg je de foutmelding..

In de TS of eerdere berichten (naast die boven deze quote) was dat niet duidelijk naar voren gekomen, vandaar dat velen dachten dat de client niet in hetzelfde domein stond, want dat zou de meest logische verklaring zijn als \\hostname niet werkt en \\hostname.domein wel.

[ Voor 3% gewijzigd door CH4OS op 30-09-2015 16:29 ]

[H8M3CuzUaintM3]

CptChaos schreef op woensdag 30 september 2015 @ 16:28:
[...]
In de TS of eerdere berichten (naast die boven deze quote) was dat niet duidelijk naar voren gekomen, vandaar dat velen dachten dat de client niet in hetzelfde domein stond, want dat zou de meest logische verklaring zijn als \\hostname niet werkt en \\hostname.domein wel.

Correct.. maar goed ze zitten allebei in hetzelfde domein zowel desktop als server...

#CONFUSED

[DigiK-oz]

Even afgezien van de terechte opmerkingen over administrative shares en de consequenties daarvan, de foutmelding geeft toch duidelijk aan dat er al een connectie met betreffende server is, met andere credentials. Door een "andere" naam op te geven, in dit geval FQDN, kom je er alsnog wel bij.

Dus, er is gewoon al een andere connectie vanaf de probleem-client naar desbetreffende server. En dat hoeft niet naar dezelfde share te zijn, een willekeurige connectie naar die server veroorzaakt dit al. En dat verklaart ook gelijk waarom het vanaf andere clients wel lukt : die hebben geen connectie met die server open staan.

[johnkeates]

Wireshark

[Question Mark]

DigiK-oz schreef op woensdag 30 september 2015 @ 16:30:
Even afgezien van de terechte opmerkingen over administrative shares en de consequenties daarvan, de foutmelding geeft toch duidelijk aan dat er al een connectie met betreffende server is, met andere credentials. Door een "andere" naam op te geven, in dit geval FQDN, kom je er alsnog wel bij.

Dat is volgens TS al opgelost.

supra_indo schreef op woensdag 30 september 2015 @ 14:56:
Net via net use even gekeken en er stond inderdaad nog een mapping naar de desbetreffende lokatie met \\ipadres\d$ deze heb ik verwijderd.

supra_indo schreef op woensdag 30 september 2015 @ 16:18:
[...]
De gebruiker gaat nu de volledige FQDN gebruiken maar voor mij is dit nog geen oplossing...

En waarom vind je dit geen oplossing? En waarom moet een user een FQDN gaan gebruiken? Het aanmaken van een drive-mapping is een eenmalig iets, wat je bijvoorbeeld ook nog centraal managed. Een user heeft toch niks te maken met de drivemapping, of op wat voor wijze deze opgebouwd wordt.

Een user ziet een driveletter, of een DFS namespace (nog mooier). Hoe en waar zijn data staat moet voor hem niet uitmaken.

[H8M3CuzUaintM3]

Question Mark schreef op woensdag 30 september 2015 @ 19:17:
[...]
Dat is volgens TS al opgelost.

[...]


[...]

En waarom vind je dit geen oplossing? En waarom moet een user een FQDN gaan gebruiken? Het aanmaken van een drive-mapping is een eenmalig iets, wat je bijvoorbeeld ook nog centraal managed. Een user heeft toch niks te maken met de drivemapping, of op wat voor wijze deze opgebouwd wordt.

Een user ziet een driveletter, of een DFS namespace (nog mooier). Hoe en waar zijn data staat moet voor hem niet uitmaken.

Aangezien het niet zomaar even een user is. Het is een ServiceDesk user die de desktop zelf onder zijn bureau heeft geplaatst om als data opslag te gebruiken(niet dat het nu hierom gaat maar toch), niet helemaal volgens de wetten van het opbouwen van een netwerk maar goed. Ik begrijp dat een c en d drive administrative drives zijn maar laten we eerlijk zijn hoevaak een D schijf tegenwoordig voor Data share gebruikt wordt op een fileserver.

Het gaat niet om een mapping, hij wil zelf handmatig vanuit explorer de lokatie benaderen om vanaf bijvoorbeeld thuis data daar neer te zetten. Nu heeft hij aangegeven dat dit fout gaat door \\hostname\c$ en \\hostname\d$.

Hij maakt dus een RDP sessie naar de desktop, die netjes in het domein zit. Vanaf die desktop connect hij vanaf een explorer naar \\hostname\c$ of \\hostname\d$ krijgt netjes een inlog scherm te zien, logt in met een domain admin account en krijgt dan de foutmelding. Gek genoeg als ik met mijn admin account inlog op de desktop via RDP en precies hetzelfde doe hoef ik dus geen credentials in te voeren als ik de connectie maak via explorer aangezien ik zelf domain admin ben. Vreemde is gewoon dat wanneer hij lokaal met zijn eigen account ingelogd zit op de desktop de credentials gebruikt van een domain admin dan krijgt hij de foutmelding.

Dus ik blijf het vreemd vinden waarom hij vanaf zijn eigen account door middel van credentials van een domain admin die connectie niet kan maken naar c$ of d$ van die server. Log ik in met mijn domain admin account op die desktop en maak de connectie dan dan werkt het wel. Allebei dezelfde rechten...

Vanaf de desktop die in hetzelfde domein zit:
\\hostname wordt netjes geopend
\\hostname.domain wordt netjes geopend
\\hostname\c$ NIET
\\hostname\d$ NIET

[ Voor 11% gewijzigd door H8M3CuzUaintM3 op 30-09-2015 19:40 ]

[Question Mark]

supra_indo schreef op woensdag 30 september 2015 @ 19:24:
[...]
Aangezien het niet zomaar even een user is.

Iedereen is een user. Een kantoormedewerker, directeur, servicedeskmedewerker of een Domain Admin. Dat iemand een bepaalde functie heeft, maakt nog niet dat de "best practices" dan niet meer gelden.

Ik begrijp dat een c en d drive administrative drives zijn maar laten we eerlijk zijn hoevaak een D schijf tegenwoordig voor Data share gebruikt wordt op een fileserver.

Data op een D-schijf prima. Deze data aanbieden via een share die daar niet voor bedoeld is, is gewoon een No-Go. Ik heb het in elk geval nog nooit gezien.

Uiteindelijk moet je het zelf weten hoor, maar weet dat er ook security templates zijn die administrative shares verwijderen....

Het gaat niet om een mapping, hij wil zelf handmatig vanuit explorer de lokatie benaderen om vanaf bijvoorbeeld thuis data daar neer te zetten. Nu heeft hij aangegeven dat dit fout gaat door \\hostname\c$ en \\hostname\d$. .

Probeer eens het echte probleem te achterhalen...

Waarom wil de servicedeskmedewerker handmatig data gaan kopieren vanaf een desktop naar een file-server?

Kennelijk vertrouwt hij (terecht) de desktop niet, en wil als een soort backup een reserve kopie van deze data hebben? Als dat het geval is, dan moet je zorgen dat zijn data veilig bewaard wordt.

• Een goede oplossing zou kunnen zijn om een backup-agent op die desktop te installeren en deze mee te nemen in de reguliere backup.
• Andere oplossing is een scheduled task, die elke nacht de data synchroniseerd naar een file-server

We zijn immers automatiseerders, dat betekent dat zoveel mogelijk automatisch moet gebeuren. Dat geeft de minste kans op fouten.

Ik heb echt het idee dat je (met heel veel inzet verkeerd) naar het verkeerde probleem kijkt. Het bedrijfsprobleem is niet het mappen van deze share. Het probleem zit hem in het stuk daarvoor.

[H8M3CuzUaintM3]

Question Mark schreef op woensdag 30 september 2015 @ 19:41:
[...]
Iedereen is een user. Een kantoormedewerker, directeur, servicedeskmedewerker of een Domain Admin. Dat iemand een bepaalde functie heeft, maakt nog niet dat de "best practices" dan niet meer gelden.

[...]
Data op een D-schijf prima. Deze data aanbieden via een share die daar niet voor bedoeld is, is gewoon een No-Go. Ik heb het in elk geval nog nooit gezien.

Uiteindelijk moet je het zelf weten hoor, maar weet dat er ook security templates zijn die administrative shares verwijderen....

[...]

Probeer eens het echte probleem te achterhalen...

Waarom wil de servicedeskmedewerker handmatig data gaan kopieren vanaf een desktop naar een file-server?

Kennelijk vertrouwt hij (terecht) de desktop niet, en wil als een soort backup een reserve kopie van deze data hebben? Als dat het geval is, dan moet je zorgen dat zijn data veilig bewaard wordt.

• Een goede oplossing zou kunnen zijn om een backup-agent op die desktop te installeren en deze mee te nemen in de reguliere backup.
• Andere oplossing is een scheduled task, die elke nacht de data synchroniseerd naar een file-server

We zijn immers automatiseerders, dat betekent dat zoveel mogelijk automatisch moet gebeuren. Dat geeft de minste kans op fouten.

Ik heb echt het idee dat je (met heel veel inzet verkeerd) naar het verkeerde probleem kijkt. Het bedrijfsprobleem is niet het mappen van deze share. Het probleem zit hem in het stuk daarvoor.

Het is geen fileserver, het is een SCCM Distributieserver waar een applicatie dir staat waar de gebruiker vanaf huis via een RDP sessie via de desktop data naar toe wil sluizen.

Kijk, de gebruiker kan \\hostname.domain\c$ en \\hostname.domain\d$ prima gebruiken, dit werkt ook maar ik wil gewoon het technische gedeelte erachter weten waarom het niet werkt met \\hostname\c$ en \\hostname\d$ ookal gaat de user geen data op die SCCM Distributieserver neerzetten, als die er maar bij kan.

1. gebruiker - RDP desktop - explorer \\hostname\d$ - credentials domain admin - foutmelding
2. domain admin - RDP desktop - explorer \\hostname\d$ - en je zit erin

Waarom werkt 1 wel en 2 niet aangezien het allebei domain admin accounts zijn welke er worden gebruikt voor de credentials.

De ServiceDesk medewerker weet dat hij op volledige FQDN er bij kan maar wil ik ben hem wel een uitleg verschuldigd...

[Question Mark]

Het enige wat ik kan verzinnen is dat er een verkeerd account gebruikt wordt....

Wat is de username die gebruikt wordt? Is dat:

• administrator
• .\administrator
• domain\Administrator
• [e-mail]

Welke foutmelding verschijnt overigens? De enige foutmelding die ik in het topic tegenkwam had te maken met het feit dat er al een sessie liep, maar dat had je al opgelost zei je.

[ Voor 26% gewijzigd door Question Mark op 30-09-2015 23:24 ]

[Hero of Time]

Nog beter, doe eens een drive mapping naar die share en geef op dat het andere credentials moet gebruiken. Ik kan je met 90% zekerheid vertellen dat dat gaat werken. Uiteraard moet de gebruiker niet eerst naar \\hostnaam\d$ zijn geweest, maar met een clean boot en sessie dat gelijk doen. Voer het desnoods via de command prompt met net use uit.

Ik heb zo het vermoeden dat er verkeerde credentials gestuurd worden bij het maken van de verbinding naar \\hostnaam en pas als die niet werken, er wordt gevraagd om gebruiker en wachtwoord. Echter is er op de achtergrond al een verbinding, met de verkeerde gegevens, opgezet en blokkeert dat de verdere pogingen. Doe maar eens een 'net use' uitvoeren nadat 't is mislukt, dan heb je die spook verbinding weer die je eerder noemde. Om dit op te lossen, open je de Credentials Manager (zoek zelf maar uit hoe dat ding in 't NL heet) en smijt de opgeslagen gegevens van het systeem.

[H8M3CuzUaintM3]

Question Mark schreef op woensdag 30 september 2015 @ 20:04:
Het enige wat ik kan verzinnen is dat er een verkeerd account gebruikt wordt....

Wat is de username die gebruikt wordt? Is dat:

• administrator
• .\administrator
• domain\Administrator
• [e-mail]

Welke foutmelding verschijnt overigens? De enige foutmelding die ik in het topic tegenkwam had te maken met het feit dat er al een sessie liep, maar dat had je al opgelost zei je.

Correct. Ik gebruik een account die lid is van domain admin. Of het nou domain\username is of dat het domein er al staat en username met password maakt niks uit... mijn eigen domain admin gaat het ook fout mee als ik het via de explorer probeer vanaf de servicedesk medewerkers account.

[Meekoh]

Luistert naar Hero of Time, Obviously heeft de gebruiker al een sessie naar de D$ share van die computer. En 2x een sessie openen naar dezelfde share (ook met andere credentials) kan niet.
Zoals aangegeven draai net use en je zult zien dat hij al een sessie heeft. Dit is echt geen rocket science of zo.

[Question Mark]

En geef de foutmelding even aan... als de GUI niks teruggeeft, kijk dan even in de eventlog van de desktop en server.

[_H_G_]

Mocht je hier nog mee bezig zijn. Wellicht meteen IPCONFIG /ALL van werkende en niet-werkende client station posten. Je zegt wel dat alles goed staat, maar soms zie je zelf de meest simpele fout niet (tenminste, heb ik regelmatig)

[Hero of Time]

_H_G_ schreef op donderdag 01 oktober 2015 @ 12:30:
Mocht je hier nog mee bezig zijn. Wellicht meteen IPCONFIG /ALL van werkende en niet-werkende client station posten. Je zegt wel dat alles goed staat, maar soms zie je zelf de meest simpele fout niet (tenminste, heb ik regelmatig)

Heb je 't hele topic wel gelezen? Het is allang duidelijk dat het juist bij authenticeren fout gaat. Het systeem zelf is niet het probleem, maar de gebruiker.

supra_indo schreef op donderdag 01 oktober 2015 @ 00:46:
[...]

Poke, want mijn reactie heb je blijkbaar niet gezien en getest.

[ Voor 16% gewijzigd door Hero of Time op 01-10-2015 15:49 ]

[H8M3CuzUaintM3]

Dit topic mag gesloten worden.

Er stond nog een connectie open naar een en dezelfde server. Ik heb deze mapping disconnected en toen werkte het

Dank voor alle reacties!

[alt-92]

Overigens is dit wel dé manier om via een gecontroleerd en veilig (geacht) distributiesysteem genaamd SCCM malware te introduceren op volledig managed clients

Srsly... handmatig iemand zooi laten kopieren naar een SCCM DP of MP.

[Hero of Time]

supra_indo schreef op donderdag 01 oktober 2015 @ 16:43:
Dit topic mag gesloten worden.

Er stond nog een connectie open naar een en dezelfde server. Ik heb deze mapping disconnected en toen werkte het

Dank voor alle reacties!

Huh? Je zei eerder al dat je alle verbindingen had verwijdert en NOG had je problemen. Hoe komt die \\hostnaam er opeens bij dan?

supra_indo schreef op woensdag 30 september 2015 @ 14:56:
[...]


Net via net use even gekeken en er stond inderdaad nog een mapping naar de desbetreffende lokatie met \\ipadres\d$ deze heb ik verwijderd.

Helaas nog steeds geen mogelijkheid om vanuit explorer te connecten via \\hostname\d$ van die server met domain credentials nog steeds dezelfde foutmelding

Dus wat was er nou echt aan de hand?

[H8M3CuzUaintM3]

Hero of Time schreef op donderdag 01 oktober 2015 @ 21:13:
[...]

Huh? Je zei eerder al dat je alle verbindingen had verwijdert en NOG had je problemen. Hoe komt die \\hostnaam er opeens bij dan?

[...]

Dus wat was er nou echt aan de hand?

Ik had via mmc, shared folders alle open files en connections naar en van de share afgesloten maar er stond inderdaad nog een mapping naar die share... nu opgelost

[H8M3CuzUaintM3]

alt-92 schreef op donderdag 01 oktober 2015 @ 20:14:
Overigens is dit wel dé manier om via een gecontroleerd en veilig (geacht) distributiesysteem genaamd SCCM malware te introduceren op volledig managed clients

Srsly... handmatig iemand zooi laten kopieren naar een SCCM DP of MP.

Gewoon een medewerker die SCCM handig is hoor... en .msi's of .exe op een share neerzetten van een SCCM server is niks mis mee hoor... zolang je er een proces op hebt draaien op de share dat er geen bestanden naar toe mogen geschreven worden is er niks aan de hand ;-)

[Hero of Time]

Laatste keer dat ik keek, werkte de 'Wijzig' knop nog gewoon. Waarom negeer je dan de waarschuwing boven de quick reply en maak je voor een aparte quote die prima in hetzelfde bericht kan een nieuwe post aan?

[Wim-Bart]

*knip* dat er nog beheerders zijn die überhaupt met domein admin rechten gekoppeld aan een generiek account werken deze tijd, is vragen om problemen. gewoon met 2 accounts werken, 1 standaard user en een admkn account met rollen voor de werkzaamheden, en desnoods een derde account met domain admin rechten voor noodgevallen.

Dat kan je ook op een vriendelijkere manier zeggen.

[ Voor 11% gewijzigd door Hero of Time op 02-10-2015 08:12 ]

[Question Mark]

supra_indo schreef op donderdag 01 oktober 2015 @ 21:49:
[...]
zolang je er een proces op hebt draaien op de share dat er geen bestanden naar toe mogen geschreven worden is er niks aan de hand ;-)

Alleen misbruik je in dit geval D$, waar gewoon schrijfrechten voor gelden....