IIS AppPool kontra Group Policy

Már írtam róla többször, hogy üzemeltetőként az egyik kedvenc IIS 7 újdonságom az Application Pool Identity, ami nagyon hasonló a Windows Server 2008 R2-ben bevezetett Managed Service Accountokhoz. Ez egy kiváló platform szolgáltatás, ám sajnos még nagyon új, ezért nem támogatja minden szoftver. Elszomorodtam, amikor ezt tapasztaltam az SQL Serverről és meglepődtem, amikor a csoportházirendekkel kapcsolatban is hasonló problémába sikerült belefutnom.

A minap ez fogadott az Application logban:

Source: SceCli

Event ID: 1202

Description: Security policies were propagated with warning. 0x534 : No mapping between account names and security IDs was done.

Szerencsére még az eseménynapló bejegyzésben le van írva, hogy mit kell tenni ilyenkor, így hamar kiderült, hogy a Default Domain Controller Policy 4 helyen hivatkozik a DefaultAppPool és a Classic .NET AppPool fiókokra, amiket azután a csoportházirend érvényesítésekor nem tud SID-hez rendelni. Persze, hogy nem, hiszen azok a fiókok az IIS AppPool nevű “domainben” vannak, tehát ezt kellene odaírni elé, és máris megtalálná.

Eddig az elmélet, a gyakorlat azonban nem ennyire szép. Windows Server 2003-ról szerkesztve a GPO-t azonnal hibát kaptam, hogy nem találja az IIS AppPool\DefaultAppPool felhasználót. Nosza átültem egy Windows Server 2008 MMC elé, ott nem volt ilyen probléma, elhitte, amit mondtam neki. Csak éppen nem mentette el, ami úgy derült ki, hogy legközelebb megnyitva a GPO-t, megint hiányzott a “domain” prefix. Az a megoldás nyilván szóba se jöhetett, hogy törlöm az érintett csoportházirend beállításokat, maradt tehát a házirend (Default Domain Controller Policy) megszerkesztése Notepaddel, amihez a fájlt itt lehet megtalálni:

SYSVOL\tartomány neve\Policies\{6AC1786C-016F-11D2-945F-00C04fB984F9}\MACHINE\Microsoft\Windows NT\SecEdit\GptTmpl.inf

Ezután egy gpupdate /force kiadásakor már nem került bejegyzés az eseménynaplóba.

A dolognak két szépséghibája van:

  • A GPO következő szerkesztésekor megint eltűnhet a tartomány előtag, méghozzá figyelmeztetés nélkül. Az érintett kulcsok a User Rights Assignment szekcióban találhatóak:
    • Adjust memory quotas for a process
    • Generate security audits
    • Log on as a service
    • Replace a process level token
  • Ugyanez előfordulhat, ha szolgáltatás fiókoknál az NT Service előtag hiányzik (pl. NT Service\WdiSystemHost).

A jó hír, hogy Redmondban tudnak a hibáról és a KB974639, valamint a KB977695 szerint van is rá hotfix, amit egyedileg lehet igényelni.

Még egy rövid, de fontos kiegészítés a témához: miután egy házirendben vagy egy mappa ACL-ben hivatkozunk egy ilyen speciális fiókra, óvatosan az alkalmazás-készlet átnevezésével, mert utána megint nem fog működni a házirend és az ACL sem fog érvényre jutni. Kérdés, hogy ezt miből vesszük majd észre?

Advertisements

One thought on “IIS AppPool kontra Group Policy

  1. Visszajelzés: IIS AppPool kontra SQL Server Agent « Balássy György szakmai blogja

Vélemény, hozzászólás?

Adatok megadása vagy bejelentkezés valamelyik ikonnal:

WordPress.com Logo

Hozzászólhat a WordPress.com felhasználói fiók használatával. Kilépés / Módosítás )

Twitter kép

Hozzászólhat a Twitter felhasználói fiók használatával. Kilépés / Módosítás )

Facebook kép

Hozzászólhat a Facebook felhasználói fiók használatával. Kilépés / Módosítás )

Google+ kép

Hozzászólhat a Google+ felhasználói fiók használatával. Kilépés / Módosítás )

Kapcsolódás: %s