windows - Er der brug for en SPN, når du bruger Kerberos med DCOM?

Indlæg af Hanne Mølgaard Plasc

Problem



Jeg bruger DCOM til at levere forskellige applikationstjenester på et Windows-netværk ved hjælp af Kerberos til at håndtere godkendelse. Systemet virker normalt fint, men jeg løber ind i problemer, der får adgang til tjenesten fra et separat (tillid) domæne. Især kan tjenesten ikke foretage tilbagekald til klientprogrammet, der modtager fejlen 'Der er opstået en specifikke fejl i en sikkerhedspakke'. Også, hvis jeg tilpasser tjenesten til specifikt at kræve Kerberos-godkendelse (i stedet for at bruge SNEGO/forhandle), kan klienten ikke engang kalde på serveren (igen modtagelse af 'Der er opstået en sikkerhedspakke-specifik fejl').


Det forvirrende er, at tingene har arbejdet i mange år uden problem. Men nogle ting er forskellige her, sammenlignet med det, vi har gjort før. For en, kører de involverede servere Windows 2008, som jeg ikke tidligere har brugt. Også som nævnt ovenfor finder fejlene kun sted, når Tjenesten er tilgængelig fra en konto fra et separat domæne, og tidligere brug har aldrig forsøgt dette.


Nu på spørgsmålet: Jeg bruger ikke et SPN (serviceledernavn) til denne DCOM-tjeneste, men nogle af fejl- og begivenhedslogfilerne får mig til at tro, at det kan være problemet. Men alle de dokumenter, jeg har fundet er uklare om dette er korrekt, eller hvordan jeg ville oprette SPN, hvis jeg har brug for det. Er der nogen der ved, om et SPN er det jeg mangler her? Hvis ja, kan du pege på, hvordan dette skal gøres?


Yderligere detaljer:


For scenariet, hvor serveren er indstillet til at tvinge Kerberos-godkendelse, kan du aktivere udvidet RPC-fejlfinding. Klienten kan med succes forbinde med CoCreateInstanceEx, men opfordrer til, at serviceinterfacet fejler som nævnt ovenfor. RPC-fejlregistrerne viser en fejl ved placering 140, og fejlkoden er 0x80090303 ('Det angivne mål er ukendt eller ikke tilgængelig'), og den tredje parameter for den pågældende post er en tom streng. Dette peger på en savnet SPN som synderen. [4]

Bedste reference


For hvad det er værd, kræver Kerberos pr. Definition SPN'er. Du kan muligvis bruge den indbyggede SPNS (vært/) og de forskellige smagsoplevelser, som værten indebærer. (Denne aliasoversættelse er gemt i AD, men for mit liv kan jeg ikke synes at finde artiklelisten hvor dette er fundet).


Jeg begynder med at kigge på krydsdomæneautentificering - Det kan være vanskeligt med kerberoer. Jeg tænder først fuld kerberos, logger på både klienten og serveren og se om det viser noget. [5]

Andre referencer 1


Jeg har stødt på denne fejl under forsøg på at oprette en forekomst af det fjerntliggende COM-objekt. Vi kan blive udsat for denne fejl. Hvis 'Delegat' -personaliseringsniveau bruges af klienten under opkaldet til CoInitializeSecurity (), og COM + -tjenesten kører under en brugerkonto, der ikke har 'delegation' -tilladelse på domæneniveau.

Andre referencer 2


Rediger : Det ser ud som om jeg måske har noget misforståelse herom. Mindst en webside, jeg fandt ud fra, angiver, at DCOM automatisk håndterer SPN'er til dig (se nederst på siden), og jeg bekræftede, at klienterne med succes kan forbinde, hvis de kræver Kerberos-godkendelse og bruger 'host/[[computername]]' som SPN. [6]





Det ser ud til, at en SPN er påkrævet for tjenesten, hvis du udtrykkeligt kræver Kerberos-godkendelse, når du ringer til CoInitializeSecurity i DCOM-serverprocessen. For mig så opkaldet sådan ud:


Advarsel: Du må ikke kopiere denne kode direkte uden at sikre, at værdierne passer til dine sikkerhedsbehov.


SOLE\_AUTHENTICATION\_SERVICE sas;
sas.dwAuthnSvc = RPC\_C\_AUTHN\_GSS\_KERBEROS;
sas.dwAuthzSvc = RPC\_C\_AUTHZ\_NONE;
sas.pPrincipalName = L"myservice/mymachine";
sas.hr = S\_OK;
CoInitializeSecurity( 0, 1, &sas, 0, RPC\_C\_AUTHN\_LEVEL\_DEFAULT,
    RPC\_C\_IMP\_LEVEL\_DEFAULT, 0, EOAC\_NONE, 0 );


SPN'en kan konfigureres ved hjælp af setspn, som vist nedenfor: [7]


setspn -A myservice/mymachine serviceusername


(se setspn docs for detaljer).


Desværre løste dette stadig ikke mit problem, men jeg tror, ​​at det resterende problem er relateret til et bestemt problem med testmaskinerne.