problem med IIS åtkomst till nätverkskatalog
 

Hej.

Lite systeminfo:
Windows Server 2008 R2-system. Domänkontrollanten heter "DK1" och rymmer bland annat gemensamma kataloger som användarna kommer åt olika delar av beroende på vilka grupper de är medlemmar i.

Det finns ett par specialkataloger på de gemensamma katalogerna där dokument som sparas i dessa kataloger automatiskt skall publiceras på en sida i webbservern. Katalogsökvägen till en av dessa är "\\DK1\gemensam\teknik\publicera\" och ett PHP-script plöjer igenom innehållet i dessa kataloger och publicerar dokument som passar mallen. Webbservern heter "WS1".

Men hur skall rättigheterna se ut på katalogen, på sharen och har det nåt med application pools user att göra? Intranet på "WS1" nås internt med "Windows Authentication" och externt med "Basic Authentication" över SSL. En tredje webbserver servar Linux-baserade informationsskärmar och använder ingen inloggning då de är kopplade på det interna nätverket. Dessa skall också kunna visa dokumenten så jag vill att själva webbservern i sig skall ha möjlighet att komma åt dessa utvalda kataloger oavsett vem eller om någon är inloggad.

Eller tänker jag fel?

PHP-skriptet... Exekveras det från webben? I så fall så kan du skapa virtuella kataloger under sajten och då får du ange ett användarnamn och lösenord som sedan används för att komma åt katalogerna. I IIS6 var det så i. Ska kika på IIS7.

EDIT: Applikationspoolens identitet bör vara samma om det ska mappas virtuella kataloger, utan virtuella kataloger är det endast applikationspoolens identitet som används.

Ok. Jag skall testa det. Jag har nu läst lite på nätet om virtual directorys men om jag fattat det rätt så blir alla filer i en VD publika och åtkomliga från siteadressen? En lösning är då att ge den ett komplicerat namn som är svårgissat. Jag använder ju ändå PHP för att skicka filen till klienten. Visserligen ligger det inte några hemliga filer i just dessa kataloger men ändå.

Förresten, vad blir då sökvägen till den virtuella katalogen i PHP-scriptet?

Ursäkta om jag rörde till det för dig. Om filerna inte skall vara åtkomliga utifrån så ska du inte använda virtual directory. Då räcker det med att sätta rätt konto på app-poolen.

Hej.

Jag har satt application pool till en som heter "Intranet". Den poolen körs med en användare som heter "iis_intranet" som ligger under "x.local/x/System Accounts".
Användaren "iis_intranet" har läsrättighet till sharen och till katalogen.

Trots detta så får jag felmeddelande "Access is denied. (code: 5)" när jag försöker läsa innehållet i katalogen "\\DK1\gemensam\teknik\publicera\".

Om jag surfar in till intranet som en inloggad användare så får jag tillgång till filerna eftersom den verkar använda dessa i stället, men då jag inte har tillgång till alla kataloger så blir det fel på dom som jag som användare inte har tillgång till.

Jag vill att alla som använder intranetsidan skall se alla meddelanden oavsett om dom ligger i normalt skyddade kataloger (genom att sätta läsrättigheter på den specifika katalogen till "iis_intranet").

Du kan inte använda ett lokalt konto på app-poolen (nja), du måste använda ett domänkonto. Det kontot måste sen ha rättigheter på "\\DK1\gemensam\teknik\publicera\".

Skapa ett konto i domänen som har tillgång till sökvägen och som har samma "user rights" på webbservern som det normala app-poolskontot. Ange sedan det kontot på app-poolen.

EDIT: Du bör undvika konton som ligger under System i domänen.

Jag verkar ha ringat in problemet. Jag har fått det att delvis fungera nu men så fort sökvägen innehåller åäö så fungerar det inte alls. Skall försöka vidare på det spåret...

Bra! åäö, då har du antagligen problem med antingen htmlencoded text (å blir egentligen ä ) eller localization.

Sökvägen ligger i källkoden och är inte hämtad från POST/GET. Källkoden är kodad i UTF8, men jag har testat även med utf8_decode() och det fungerar inte heller.

Ok, men det låter ändå som något problem med att åäö inte blir åäö i filanropet. Prova att köra Process Monitor på servern och logga alla nätverksanrop. Då borde du se vilket anrop det är som ställer till det och hur windows "ser" anropet.