J'ai post=E9 l'article suivant dans microsoft.public.platformsdk.security=
,=20
mais comme les r=E9ponses tardent =E0 venir, je tente ici...
> On a Windows 2003 Domain Controller, a Windows service (running as=20
DOMAIN\USER) eceives Kerberos SSP tokens from client applications.
>
> If the Windows service is started manually, AcceptSecurityContext=20
returns 0 (meaning GSS_S_COMPLETE) and I can get the initiator's name=20
from the context and impersonate the context: everything is fine.
>
> However, if the Windows service is automatically started upon reboot, =
then AcceptSecurityContext returns SEC_I_CONTINUE_NEEDED and I cannot=20
use the (not yet available) context.
>
> [Note: I know that this behaviour is conform to both GSS-API and=20
SSPI, but due to restrictions in the client/server protocol, I cannot=20
use more than one exchange to establish the context.]
>
> We already discovered that, *upon reboot*, the Windows service could=20
not acquire its Kerberos SSP credentials (using=20
AcquireCredentialsHandle) when configured with an account name with a=20
Kerberos format: user@realm. We had to set the SAM account name=20
(DOMAIN\USER) in the Windows service configuration.
Calling QueryCredentialsAttributes on the acquired service credentials=20
shows the following user's UPN:
=2E upon reboot: USER@dns.domain.name@
=2E after restart: USER@DNS.DOMAIN.NAME
I guess I should perform the windows service user's logon again to get=20
full Kerberos credentials. Unfortunately, using QueryServiceConfig I can =
only get the user's name (and not the password: that's nice from a=20
security point of view but a problem in my case ;-) .
Question: is it possible for a service to ask its own restart ? Or=20
should the service use CreateProcess to launch an program that in turn=20
performs the stop/start of the service? Would such a tricky thing work?
>
>
> I reckon that upon reboot, the domain controller is not (fully)=20
available to perform the ""Kerberos"" authentication of the starting=20
service. This is confirmed when installing the same service on any other =
host of the domain (running Windows XP or Windows 2003 server): upon=20
reboot, if the domain controller is available, then the=20
AcceptSecurityContext call always returns 0 (meaning GSS_S_COMPLETE); if =
the domain controller is not reachable, then AcceptSecurityContext=20
returns either 0 or CONTINUE_NEEDED, probably depending on Kerberos=20
tickets cache contents???
>
>
> Can anybody confirm my assumptions ?
>
