Udostępnij za pośrednictwem

A high level overview of Windows CE Web Server authentication.

  • Artykuł

How does the Windows CE Web Server handle authentication?

Web server authentication is already documented at https://msdn2.microsoft.com/en-us/library/aa922781.aspx (CE 6.0).  Based on the number of questions on the newsgroups I get about web server authentication I think I'll try to restate some of the key points.  The actual details will remain in the MSDN docs; this is only a supplement.

Web server auth is a 3 stage process
(1) Is specified user name / password valid?
(2) If credentials are valid, does the user have access for requested virtual root?
(3) If user has access for virtual root, what operations do they have permission to perform?

Let's look at each of these in turn
STAGE (1):  CHECKING CREDENTIALS

Web server authentication is configured per virtual root (vroot).  The documentation describes the registry settings required to make a vroot require auth.  Setting the DWORD "A" = 0 (the default) means anyone can access the vroot, a=1 means user name and password is required, a=2 means that user name and password is required and the user must be in the AdminUsers list.

When an HTTP request comes to the Web server, if it detects that a virtual root with a >=1 is requested, it will send back a "401 - Unauthorized" code to the client browser.  It will also indicate which authentication mechanisms it supports.  CE Web server currently supports Basic and NTLM based authentication.

The web browser will either use cached credentials or prompt the user for a username / password, depending on how it is configured.  It will send the user name and password in (effectively) clear text for basic, and do some crypto magic on NTLM to avoid sending clear text passwords.

How does CE determine whether a user name / password is legit?  It depends on whether the registry value HKLM\COMM\Redir\DefaultDomain is set or not.  If this value is set, then the web server will contact the domain controller associated with the specified domain and ask it to validate whether the user / password combination is recognized.  Put the domain name, and not the domain controller name, in this field.

If this registry value is not set, then the Web server will use the local CE accounts database.  New users can be added at runtime by calling the NTLMSetUserInfo() API.  There are similar helper API's for other operations, like deleting users.  See MSDN for details.

If the credentials are valid, we move on to stage 2.  Otherwise Web server sends back a "401 - Unauthorized" and we begin the process again.

STAGE (2): CHECKING ACCESS
Let's assume a user gave us a name/password that CE HTTPD validates is a real user account.  Next we see if this user has access for this virtual root.  For instance, a virtual root for administering a device may be available for mom and dad to configure but not be something we want the kids messing with.  To do that, the Web server looks at the "UserList" registry value of the request virtual root.  This is a poor man's ACL.  It allows giving access or denying both individual users and groups.  The rules are rather complicated, so I'll refer you to MSDN for details.

If there is no "UserList" and A=1, then a user will automatically gain access once they pass STAGE 1.  If A=2, then they must be in the AdminUser list (similar ACL format registry string).

STAGE (3): PERMISSIONS
Let's say our user gets past stage 2.  They do not have infinite control over the virtual root.  There is a 3rd line of security - the permissions granted.  Possible permissions to grant or deny include reading, writing (for WebDAV), scripting+execution (for ISAPI extensions + ASP pages).  Permissions are set per virtual root.  They are configured (surprise, surprise) via a registry setting - "p".  Again, this is a bit complicated so see MSDN for reference.

Even a user who is an Admin does not have permissions exceeding those configured with the virtual root.  So if a virtual root does not grant write access, even an Admin cannot write to it.

The default Web server permissions if no "P" is set are "read", "execute ISAPI's", and "execute ASP pages".

--

Final thought: The same thing you hear about other web servers and security holds for CE as well.  Give the minimum number of users access to the minimum number of features, know what you're doing, and you'll have a minimum number of headaches.

[Author: John Spaith]

Comments

  • Anonymous
    June 09, 2005
    Very good! Maybe i don´t know how to search the documentation, but it would be nice to see this merged on the msdn help... Also, On the See also topics, should appear the NTLMSetUserInfo api, because it´s really related!