Re: Checking for NT domain existance

From: John Spaith [MS] (jspaith_at_ONLINE.microsoft.com)
Date: 06/16/04 

Date: Wed, 16 Jun 2004 14:45:13 -0700

In CE 5.0 we've added the API DsGetDcName(), which can lookup a domain to
see if it exists and also get you useful information about it, like the
domain controller name, etc. You're on CE 4.2 of course, so this doesn't
help.

I talked with the local security gurus and they said even if you had this
API on 4.2, it would not be completely safe. Just because the domain
existed would not necassarily mean you could authenticate against it. You
could still end up in the state where your device was inaccessible.

The safe way to do this is to actually authenticate a user against the
domain before "committing" the DefaultDomain change. Of course now you have
a chicken and egg problem because you have to write this registry value out
even before you know whether it's safe or not and then do you
authentication. I can think of some workarounds (hacks is a better word) to
this.

(1)
If you're using SSL, you could prompt the user for their user name and
password in the FORM at the same time they updated the domain. Obviously
doing this in clear is scary, unless you %100 trust the network, which I
wouldn't do. After you have userName/password for a valid domain account on
CE device, you then write out DefaultDomain and then try to authenticate
with that user/password. If it succeeds then you're done. If it fails back
out the DefaultDomain change.

How do you authenticate a user on CE? You can do it using the NTLM SSPI
directly, but we have a set of helper utilities that web server/telnet/ftp
use to do their user authentication. The functions are defined in authhlp.h
and are implemented in authhlp.lib. (I believe you have to be an OEM to get
at these, but I may be wrong.) You would then do:

AuthHelpInitialize();
AuthHelpValidateUserW(szUserName,szPassword,NULL,0); // TRUE if you can
auth, FALSE if authentication fails for whatever reason (bad password,
*can't find domain*, etc...).

Getting SSL setup on a headless is another can of worms unfortunatly. If
you do do this, call RtlSecureZeroMEmory on the user name and password once
you're done using it to increase security. Don't use memset() since the
compiler map optimize it out. Here's code for this function:

FORCEINLINE
PVOID
RtlSecureZeroMemory(
    IN PVOID ptr,
    IN SIZE_T cnt
    )
{
    volatile char *vptr = (volatile char *)ptr;
    while (cnt) {
        *vptr = 0;
        vptr++;
        cnt--;
    }
    return ptr;
}

(2)
If you don't have SSL, then if there is some dummy account that can be sent
across to auth against then consider this. Steps would be identical to (1)
except that the web browser user would enter in these bogus credentials
instead of their real credentials. Ideally this would be like a guest
account or something with even less priveleges - the only thing the account
can do is be authenticated against.

If you're having individual users configure this and not domain admins, then
getting them information about the dummy account would be hard. I don't
think many admins would like creating a useless account for these purposes.
I'm throwing this out however in hopes it may inspire you to think of
something better.

(3)
Write out DefaultDomain and don't worry at all whether it will work or not.
The web page HTML should auto-redirect to a page that requires auth (maybe
allow a few seconds if you're doing other config settings). This should
then prompt user for userName/Password.

To handle bogus domain scenario, once you write DefaultDomain start up a
timer - say give it a timeout of 30 seconds or whatever. If your ISAPI is
accessed, then stop the timer because it means the domain is OK. If however
the timer fires, then assume the DefaultDomain is bogus.

Don't tie this timer to your ISAPI extension itself unless you do an extra
LoadLibrary() on your ISAPI to make sure web server doesn't unload your
ISAPI on a HTTP refresh or when it clears its cache every 30 minutes. 

--
I hope you can think of something more eloquent here, but this hopefully
will get you on the right track.
-- 
John Spaith
Software Design Engineer, Windows CE
Microsoft Corporation
Have an opinion on the effectiveness of Microsoft Embedded newsgroups?  Let
us know!
https://www.windowsembeddedeval.com/community/newsgroups
This posting is provided "AS IS" with no warranties, and confers no rights.
You assume all risk for your use. © 2003 Microsoft Corporation. All rights
reserved.
"RockinFewl" <rockinBUBBLE@WRAPwhirlywiryweb.com> wrote in message
news:%23v3aSa4UEHA.1356@TK2MSFTNGP09.phx.gbl...
> Hi all. Little story ahead, with a perhaps tough question at the end...
>
> Context:
> We're considering web services to perform device management of a
> headless WinCE4.2 device.
> To quickly authorize web requests, we perceive NTLM authentication as a
> mainstream and secure way to go. Currently we can succesfully
> authenticate local users (the kind defined with NTLMSetUserInfo), and
> domain users.
>
> The WinCE device selects the security provider (local or domain),
> depending on the value of the HKLM/Comm/Redir/DefaultDomain registry
> key. Also this key can be written through a web service, allowing to
> switch domains, or to switch to the local security provider. The new
> security provider is immediately effective.
>
> Problem with this last operation is... what if the web service client
> writes a bogus domainname, or puts a typo in it.
> The headless WinCE device will then immediately authenticate against an
> unexisting domain, so the device will be no longer accessible.
>
> Question:
> Is there any way to check for the existence of a NT domain from WinCE?
> The web service ideally should do this before setting it as new security
> service provider.
>
> Thanks heaps,
> Koen.
>

Relevant Pages

  • Re: Checking for NT domain existance
    ... The safe way to do this is to actually authenticate a user against the ... you then write out DefaultDomain and then try to authenticate ... then if there is some dummy account that can be sent ... or to switch to the local security provider. ...
    (microsoft.public.windowsce.app.development)
  • Re: Checking for NT domain existance
    ... > existed would not necassarily mean you could authenticate against it. ... > domain before "committing" the DefaultDomain change. ... After you have userName/password for a valid domain account on ... If your ISAPI is ...
    (microsoft.public.windowsce.embedded)
  • Re: Checking for NT domain existance
    ... > existed would not necassarily mean you could authenticate against it. ... > domain before "committing" the DefaultDomain change. ... After you have userName/password for a valid domain account on ... If your ISAPI is ...
    (microsoft.public.windowsce.app.development)
  • Design/Pattern guidance to refector my current design for unit testing
    ... short requiredRoleID, out UserAccount account); ... When the application consuming AuthMgr starts up, ... Authenticate auth = new Authenticate; ... // This stuff is all here so I can unit test the authentication system ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Child Domain access
    ... > You wrote...."So you logon TO A PC using a set of credentials from a ... > should be able to authenticate in the child domain with domain / ent admin ... > account which exists in the TRUSTED parent domain? ... So if the PC is in the child domain you can logon to IT ...
    (microsoft.public.windows.server.active_directory)