none
SBS 2008 - ověřování Kerberos

    Dotaz

  • Dobrý den!

    V naší společnosti máme dva servery v jedné doméně. (Primární řadič AD je samozřejmě na prvním serveru.)
    1) SERVER_1 - Windows SBS 2008 Premium 
    2) SERVER_2 - Windows 2008 Standard

    Problém je následující:
    Pokud na SERVER_2 nainstaluji službu (service) a nastavím ji, aby se spouštěla pod účtem "Local System" tak funguje správně integrovaná Windows autentifikace  (ověření jména a hesla zadaného při přihlášení do domény). (Tuto službu však nechci spouštět pod "Local system", protože pak nemůžu na SERVERU_1 v SQL nastavit práva pro tuto službu, a existují i další důvody týkající se práv, proč nechci tuto službu spouštět pod systémem)

    Pokud službu spustím pod AD účtem např. "ABC", který má práva "Domain Admin" (ale zkoušel jsem přiřazovat snad všechny existující práva, abych to vyzkoušel), tak přestane ze SERVER_1 fungovat přihlášení k aplikaci dané služby, tedy nefunguje integrovaná Windows autentifikace (kterou zajišťuje Kerberos) pro tuto službu. (Když vyplním jméno a heslo znovu ručně, tak se to přes NTLM ověří.)

    Jak mám pro uživatele ABC nastavit, aby se choval stejně jako "Local System" pro danou service ???

    (Pozn.: delegování libovolné službě mám pro účet ABC mám povoleno.)

    25. listopadu 2009 15:56

Odpovědi

  • Dobrý den,

    zrušte uživatele s právy Domain Admin a s ním zároveň unconstrained delegaci. Nikdy více nepoužívejte delegování libovolné službě. (na druhou stranu je to pěkný bezpečnostní kráter, s tím se dá provést kde co)

    Důležité je rozhodnutí zda Kerberos vůbec potřebujete. Představíme-li si následující scénář s třemi počítači uživatel usr1@domain na KLIENT --> APPSERVER --> DBSERVER, tak Kerberos a s ním spojenou delegaci potřebujete pouze v případě, že na serveru DBSERVER se musí autentizovat přímo uživatel usr1@domain, jinak vám stačí NTLM. Mnoho aplikací využívá přístup skrze svůj aplikační účet.
    Schematicky:

    Kerberos s delegací
    usr@domain on CLIENT -usr@domain-> APPSERVER -usr@domain-> DBSERVER

    Stačí NTLM, nebo kerberos bez delegace
    usr@domain on CLIENT -usr@domain-> APPSERVER -app@domain-> DBSERVER

    Kritická věc, která vám pro fungování Kerbera schází je SPN (Service Principal Name)

    Mám-li být specifický, potřeboval bych další indicie, tj. co je klientem, jsetli je to Internet Explorer nebo něco jiného, co je aplikace - IIS web nebo nějaká jiná a co je databáze jestli microsoft SQL či co.


    2. prosince 2009 1:34
  • Dobrý den,

    spíš bych se zaměřil na app.config jak služby, tak aplikace. Integrovaná autentizace znamená, že se použije Negotiate, tj. prvně se pokusí o Kerberos, a když to nevyjde, tak zkusí NTLM. Pokud nepotřebujete delegovat z ABC_Service uživatele někam dále do databáze, je NTLM postačující mechanizmus. Čili nepotřebujete SPN ani nic takového.

    Ve WCF, lze přímo v kódu vynutit použití Kerbera, pak tedy mechanismus musí být Kerberos, SPN je dobře nakonfigurované, ale musí být také uvedenou v obou app.config, aby aplikace věděla co vlastně hledá, když bude žádat o TGS.

    7. prosince 2009 22:09

Všechny reakce

  • Dobrý den,

    zrušte uživatele s právy Domain Admin a s ním zároveň unconstrained delegaci. Nikdy více nepoužívejte delegování libovolné službě. (na druhou stranu je to pěkný bezpečnostní kráter, s tím se dá provést kde co)

    Důležité je rozhodnutí zda Kerberos vůbec potřebujete. Představíme-li si následující scénář s třemi počítači uživatel usr1@domain na KLIENT --> APPSERVER --> DBSERVER, tak Kerberos a s ním spojenou delegaci potřebujete pouze v případě, že na serveru DBSERVER se musí autentizovat přímo uživatel usr1@domain, jinak vám stačí NTLM. Mnoho aplikací využívá přístup skrze svůj aplikační účet.
    Schematicky:

    Kerberos s delegací
    usr@domain on CLIENT -usr@domain-> APPSERVER -usr@domain-> DBSERVER

    Stačí NTLM, nebo kerberos bez delegace
    usr@domain on CLIENT -usr@domain-> APPSERVER -app@domain-> DBSERVER

    Kritická věc, která vám pro fungování Kerbera schází je SPN (Service Principal Name)

    Mám-li být specifický, potřeboval bych další indicie, tj. co je klientem, jsetli je to Internet Explorer nebo něco jiného, co je aplikace - IIS web nebo nějaká jiná a co je databáze jestli microsoft SQL či co.


    2. prosince 2009 1:34
  • Dobrý den,

    popíšu přesně o co se jedná:

    Lidé v naší firmě vyvinuli vlasní software:
    1) windows službu "ABC_service" napsanou v .NET (3.5) která komunikuje s klientem pomocí WCF (TCP binding - použito message security) přičemž komunikace se šifruje a klienti se autentifikují pomocí integrované windows autentifikace.
    2) aplikace "ABC_aplikace" napsaná taky v .NET (3.5) komunikuje s "ABC_service".
    "ABC_service" je nainstalovaná na SERVER_2 a běží pod uživatelem "ABC_user"

    Pokud aplikaci "ABC_aplikace" spustím jinde než na SERVER_2 tak nefunguje integr. windows atintifikace.

    SPN (Service Principal Name) jsem při nastavování delegování nastavil takto:

    setspn –a ABC_service/SERVER_2 ABC_user
    setspn –a ABC_service/SERVER_2.domain.local ABC_user

    Přesto to nefunguje.

    2. prosince 2009 12:43
  • Dobrý den,

    spíš bych se zaměřil na app.config jak služby, tak aplikace. Integrovaná autentizace znamená, že se použije Negotiate, tj. prvně se pokusí o Kerberos, a když to nevyjde, tak zkusí NTLM. Pokud nepotřebujete delegovat z ABC_Service uživatele někam dále do databáze, je NTLM postačující mechanizmus. Čili nepotřebujete SPN ani nic takového.

    Ve WCF, lze přímo v kódu vynutit použití Kerbera, pak tedy mechanismus musí být Kerberos, SPN je dobře nakonfigurované, ale musí být také uvedenou v obou app.config, aby aplikace věděla co vlastně hledá, když bude žádat o TGS.

    7. prosince 2009 22:09
  • Dobrý den,

    děkuji za odpověď.
    SPN potřebovat budeme (protože service sahá do MSSQL pro data).

    Informaci jsem předal našim vývojářům a ti byli tak drzí, že chtěli abych se zeptal, jak "app.config" upravit.
    Proto prosím, zda byste (pokud to pro Vás není nějak obtěžující) mohl napsat, co ve WCF v app.config nastavit.

    Předem velice děkuji.

    11. prosince 2009 7:54