GetComputerObjectName() fails when called in auto-start serviceat boot time
in [Win32 Kernel]
|
Prev: GetComputerObjectName() fails when called in auto-start service at boot time
Next: Mapping memory of another process
From: Chuck Chopp on 13 Sep 2006 12:28 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. 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. -- 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: Chuck Chopp on 13 Sep 2006 17:17 Ben Voigt wrote: > 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. One additional piece of information... the services *is* running on a DC. In fact, in all of the scenarios where this failure occurs, it's running on a DC. > Try a dependency on "Workstation" and "Server" Microsoft-provided services? I'll give that a try. Setting up service dependencies on NetLogon didn't affect the outcome and the failure still occurred. -- 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: Chuck Chopp on 13 Sep 2006 17:18 Skywing [MVP] wrote: > Perhaps "Netlogon". No, that one didn't affect the outcome and the failure still occurred. It would be helpful to know with more certainty how this error ends up being returned and what underlying conditions exist at the time it occurs. However, since it only happens at boot time there's some difficulty in getting any time of debugger control over the system w/o altering the run-time environment to the point where the failure won't occur under debugger control. -- 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: Chuck Chopp on 14 Sep 2006 10:28 Slava M. Usov wrote: > "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. 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? 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. I don't see how it could be a version mismatch issue. -- 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: Chuck Chopp on 16 Sep 2006 18:21
Slava M. Usov wrote: > "Chuck Chopp" <ChuckChopp(a)rtfmcsi.com> wrote in message >>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. Right... I've tried waiting on SamSs, etc... and even though the service is started, it's not fully functional. I've nearly decided to code a delay/re-try loop to get around this problem. Otherwise, I may make some sort of basic test function that I call 1st that uses DsBind() to attempt to bind to a DC int the local domain and wait on success before I allow the service to continue initializing. Or, if there's a better way to test for AD being fully functional on the DC, I'd be interested to know about it. -- 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. |