GetComputerObjectName() fails when called in auto-start service at boot time
in [Win32 Kernel]
|
Prev: loadlibrary mfc exe
Next: GetComputerObjectName() fails when called in auto-start serviceat boot time
From: Ben Voigt on 13 Sep 2006 12:15 "Chuck Chopp" <ChuckChopp(a)rtfmcsi.com> wrote in message news:OEEriJ01GHA.4908(a)TK2MSFTNGP02.phx.gbl... >I have a service that needs to obtain the FDN [Fully Distinguished Name] of >the local system's computer object in AD. This service is set to >automatically start at boot time and runs as the "Local System" account. > > On some systems, the API function GetComputerObjectName() fails and > returns zero. A call to GetLastError() obtains a negative decimal value > that can be expressed in hex as 0x80090350. Given that the negative > decimal value has no apparent meaning as a Win32 error code, and that the > hex representation appears to be a COM HRESULT value, I looked it up and > here's what I found in one of the Windows SDK header files: > > // > // MessageId: SEC_E_DOWNGRADE_DETECTED > // > // MessageText: > // > // The system detected a possible attempt to compromise security. Please > ensure that you can contact the server that authenticated you. > // > #define SEC_E_DOWNGRADE_DETECTED _HRESULT_TYPEDEF_(0x80090350L) > > > What I'm trying to do now is to identify *why* this error is occurring and > what it's significance is. I'm not sure if there is a misconfiguration > issue, something broken in AD or in the server's domain membership, or if > there's simply a service startup order dependency problem of some sort. > > Any ideas? > Sounds like Windows used cached credentials to log you in, and they aren't good enough for what you need. > > TIA, > > Chuck > -- > Chuck Chopp > > ChuckChopp (at) rtfmcsi (dot) com http://www.rtfmcsi.com > > RTFM Consulting Services Inc. 864 801 2795 voice & voicemail > 103 Autumn Hill Road 864 801 2774 fax > Greer, SC 29651 > > "Racing to save lives" > The Leukemia & Lymphoma Society - Team in Training > http://www.active.com/donate/tntsc/tntscCChopp > > Do not send me unsolicited commercial email.
From: Ben Voigt on 13 Sep 2006 13:31 "Chuck Chopp" <ChuckChopp(a)rtfmcsi.com> wrote in message news:OSCQdG11GHA.3656(a)TK2MSFTNGP04.phx.gbl... > Ben Voigt wrote: > >> Sounds like Windows used cached credentials to log you in, and they >> aren't good enough for what you need. > > Hmmm... I'd accept that *if* my service was logging on as a domain user > while the member server was in a disconnected state and then the API > function was called *after* the member server was reconnected to the > network & in communication with a DC. > > However.... > > My service is configured to run as "Local System" and thus does not > explicitly peform a logon using any credentials. In terms of access to > AD, it has the same identity as the member server itself, which is the > server's machine account. Which still needs to use the domain controller, I believe, to verify that the computer is still a member of the domain. Until you get your network up, you'll have a cached credential. > > Now, here's the part that makes me think it's an as yet unidentified > service startup order dependency issue.... > > When the failure occurs, it is always when the service is being > automatically started at boot time. After the system has completed > booting, I can manually start the service w/o any problems. > Try a dependency on "Workstation" and "Server" Microsoft-provided services? > > -- > Chuck Chopp > > ChuckChopp (at) rtfmcsi (dot) com http://www.rtfmcsi.com > > RTFM Consulting Services Inc. 864 801 2795 voice & voicemail > 103 Autumn Hill Road 864 801 2774 fax > Greer, SC 29651 > > "Racing to save lives" > The Leukemia & Lymphoma Society - Team in Training > http://www.active.com/donate/tntsc/tntscCChopp > > Do not send me unsolicited commercial email.
From: Skywing [MVP] on 13 Sep 2006 15:46 Perhaps "Netlogon". -- Ken Johnson (Skywing) Windows SDK MVP "Ben Voigt" <rbv(a)nospam.nospam> wrote in message news:OBusCq11GHA.1256(a)TK2MSFTNGP02.phx.gbl... > > "Chuck Chopp" <ChuckChopp(a)rtfmcsi.com> wrote in message > news:OSCQdG11GHA.3656(a)TK2MSFTNGP04.phx.gbl... >> Ben Voigt wrote: >> >>> Sounds like Windows used cached credentials to log you in, and they >>> aren't good enough for what you need. >> >> Hmmm... I'd accept that *if* my service was logging on as a domain user >> while the member server was in a disconnected state and then the API >> function was called *after* the member server was reconnected to the >> network & in communication with a DC. >> >> However.... >> >> My service is configured to run as "Local System" and thus does not >> explicitly peform a logon using any credentials. In terms of access to >> AD, it has the same identity as the member server itself, which is the >> server's machine account. > > Which still needs to use the domain controller, I believe, to verify that > the computer is still a member of the domain. Until you get your network > up, you'll have a cached credential. > >> >> Now, here's the part that makes me think it's an as yet unidentified >> service startup order dependency issue.... >> >> When the failure occurs, it is always when the service is being >> automatically started at boot time. After the system has completed >> booting, I can manually start the service w/o any problems. >> > > Try a dependency on "Workstation" and "Server" Microsoft-provided > services? > >> >> -- >> Chuck Chopp >> >> ChuckChopp (at) rtfmcsi (dot) com http://www.rtfmcsi.com >> >> RTFM Consulting Services Inc. 864 801 2795 voice & voicemail >> 103 Autumn Hill Road 864 801 2774 fax >> Greer, SC 29651 >> >> "Racing to save lives" >> The Leukemia & Lymphoma Society - Team in Training >> http://www.active.com/donate/tntsc/tntscCChopp >> >> Do not send me unsolicited commercial email. > >
From: Slava M. Usov on 13 Sep 2006 17:20 "Chuck Chopp" <ChuckChopp(a)rtfmcsi.com> wrote in message news:OEEriJ01GHA.4908(a)TK2MSFTNGP02.phx.gbl... [...] > // > // MessageId: SEC_E_DOWNGRADE_DETECTED > // > // MessageText: > // > // The system detected a possible attempt to compromise security. Please > ensure that you can contact the server that authenticated you. > // > #define SEC_E_DOWNGRADE_DETECTED _HRESULT_TYPEDEF_(0x80090350L) > > > What I'm trying to do now is to identify *why* this error is occurring and > what it's significance is. This could be caused by a version mismatch of the NTLM dialect the two systems use, or something similar. Usually more info is logged in the Windows event log. S
From: Slava M. Usov on 15 Sep 2006 19:16
"Chuck Chopp" <ChuckChopp(a)rtfmcsi.com> wrote in message news:OQTTBoA2GHA.1300(a)TK2MSFTNGP05.phx.gbl... >> This could be caused by a version mismatch of the NTLM dialect the two >> systems use, or something similar. Usually more info is logged in the >> Windows event log. > > I'll check again, but nothing leapt out at me in the eventlogs as being > related to this problem. Should I expect this to be in the Sytem eventlog > instead of the Application eventlog? System log, reported by LSA or SAM or SCHANNEL or something like that. > Also, relating to the version mismatch issue, I'm seeing this problem with > my service running on the only DC in a single domain forest. Ah. Then it seems to be very simple: the call involves talking to a DC, but the DC is not available yet, because the DC is still booting up. Your code being a service on a DC essentially cannot avoid the problem; the only thing to try is a dependency on the LSA/SAM service -- if I remember correctly, this is where the DC proper resides. But even this can fail, even without running on a DC -- things responsible for networking on Windows are not completely initialised even when all services indicate "running", so your service should be tolerant to weird failures early in the boot-up sequence -- wait and retry usually do the thing. S |