UWWI FAQ - How Things Work
In addition to explanations of basic Windows technology, this document also includes
explanations relevant to the more complex cross-forest scenarios that are relevant
here at the UW. We welcome suggestions as to additional questions that should be added
to this document.
What are the default users
& groups in Windows?
How does the Windows authentication mechanism work? And
how does Windows authorization work?
Depending on the type of Windows login, you get a portion of your authorization along with your authentication. For an interactive
login (what you do when you hit ctrl-alt-del), you get a login token that contains all your domain-based global and universal groups
attached.
During the login process, you present a password to your workstation. Your workstation
contacts the domain controller, negotiates an authentication mechanism, then in
slightly different ways dependent on the mechanism, interacts with the domain controller
to check if your password is correct. If it is, a login token of the type of authentication
mechanism negotiated is issued you on your workstation.
Which authenticaton mechanism is used depends on a negotiation between your workstation
and the domain controller. Specifically, it depends on the setting called the LmCompatibilityLevel.
Read more about that here.
When you then try to access a remote resource, that login token (the interactive one) is passed to the remote server, like
IIS, to perform a different kind of Windows login--a network login. As a user, you don't see that login happening--unless it isn't
accepted. In the background, you as a user are passing your login token to the server and allowing the server to do a limited number
of things with that token. One of those things is to examine the token for the domain-based global and universal group memberships.
Another is to construct the other group memberships that you are entitled to. The other group memberships include domain-based local
groups, computer-based local groups, and dynamic group memberships. These other group memberships must be constructed at the time of
access because they are context specific--e.g. there are many possible domains/computers that you *might* access and so only those
memberships are constructed when needed. The remote server then makes an authorization decision based on whether you possess a group
or user principal that is allowed the "logon over the network" user right on that remote server. Then it makes another decision as to
whether you possess a group or user principal that corresponds to an allow ACE in the ACL on the resource you tried to access.
So ... authentication is tied to authorization in Windows. With Windows it's not a one to one mapping, but it is inexorably mated together.
Are other types of authentication allowed besides Kerberos?
Yes, but it is limited. NTLMv2 and NTLMv1 authentication are allowed. LANMAN and cleartext authentication are not permitted. We recommend that where possible either Kerberos or NTLMv2 be used.
Go to top
of page
How does the authentication mechanism get chosen? What's the LmCompatibilityLevel
setting?
Which authenticaton mechanism is used depends on the configuration of your workstation
and the domain controller. Specifically, it depends on the setting called the LmCompatibilityLevel.
This setting determines which mechanisms are allowed to be sent and received. If
the client and domain controller don't share at least one mechanism in common, then
authentication will fail, and appear in the security event log as "Unknown user
name or bad password". The authentication mechanism re-enters the picture later
if you try to use the token you've been granted to access a resource on a server.
At that point, if the server doesn't allow tokens of the authentication mechanism
you negotiated with the domain controller, then you will fail to access the server
with an "access denied" error.
You may see problems like those described in the FAQ
I can login on some computers but not others. Why is this
happening? You may also see problems like those described in
the FAQ I can login with my UWWI user account, but I can't access resources on a
server even though I've granted that account access. What is wrong?.
What
should my LmCompatibilityLevel settings be? describes how to set the LmCompatibilityLevel
to a value that is optimal for the UW Windows Infrastructure.
Go to top of page
I have Windows 95, Windows 98, and Windows NT 4 workstations in my
department, which obviously don’t have Kerberos. How do they participate with UWWI?
It depends on what type of participation you want. In general, Windows
workstations of any modern flavor (NT or 9x) should be able to access shared
resources that trust
the UWWI, whether they are members of a domain that trusts UWWI or
not. Access to these resources will require NTLMv2 or NTLMv1 authentication, which will
require local administrators of Windows 9x machines to install the Active
Directory Client and will require configuration for either NTLMv1 or NTLMv2 authentication.
Both platforms can join a Windows 2000 domain for authentication. They will
not, however, receive group policy from the domain.
Go to top
of page
How does someone in my department get access to files on someone else’s
computer in another department?
This requires a small amount of coordination with someone who has the privileges
to administer file shares on the destination computer. The adminstrator of the destination
computer can either give a single UWWI user account access or an entire group access
to the shared files. Then your the person in your department can provide their UWWI
credentials to access the resource.
In the future, UWWI may offer DFS, Distributed File Service, functionality that
will allow departments to publish their shared file resources in a hierarchical
tree. This would simplify the process of getting to resources for users, while also
providing the benefit of a static target "link" that clients know about, such that
administrators can swap the backend server behind that link with relative ease and
virutally no impact on clients.
Go to top
of page
Can I restrict everyone except members of my domain from logging into our
department's workstations?
Yes. Windows has a grantable user right called "logon locally". By
default, the general "Users" group has this right. You can restrict this on a
machine by machine basis to another group or account (via "local security
settings" under administrative tools). You can also set this right via group
policy on an OU-wide basis (so every machine in your OU is affected) or on a
domain-wide basis. The group policy object for this setting is located under
computer/windows/security/local policies/user rights/logon locally (& deny
logon locally), and one designates the groups you want to give access (or deny
access).
Go to top
of page
How do we handle students who walk away from public workstations leaving
themselves logged on? Can we set Kerberos ticket lifetimes on our OU?
You can't set Kerberos ticket lifetime on an OU basis, nor can you affect the ticket
lifetime set on UWWI accounts. Kerberos ticket lifetimes can only be set via a group
policy object on a domain-wide basis--so the lifetime chosen for UWWI user accounts
is shared by all.
However, several alternatives would better address this situation. The
Windows resource kit has a tool just for this situation called WinExit
(winexit.scr). It is a screen saver which logs the current user off the computer
after a designated time period. One designates an idle time, and then this tool
kicks in. When it is launched, a window appears and a countdown (which you
specify) begins. The logoff can be aborted by the user by clicking on a button
within this window.
This option can be used by placing all your public workstation in an OU
by themselves. This OU would need a GPO which enabled loopback group policy
editing (so you could set the important settings based on the machine and not
the user). The machine GPO would be a combination of a registry key
modification, and a software installation (the tool). Additionally, the GPO
would have several user settings under user/admin/control panel/display to
designate the right options, including the screensaver activation time, etc.
There are public workstations where the activity doesn’t keep the screensaver
from being triggered. For example, playing a movie or musical recording via the
CD/DVD drive doesn't prevent the screensaver from being triggered. These exception
cases can be handled a couple ways. One would be to specify their machine
accounts as exceptions to the GPO. There wouldn't be any logout protection in
this case. Another would be to except those machine accounts, and create an
alternate GPO which only applied to that handful of machines. You could set the
timeout higher, say 3 hours or the longest movie time in your collection.
Another way to deal with it is to just tell the few users at those workstations
that they'll have to click the abort logout button when it comes up.
Go to top
of page
I have public Windows workstations. How do I restrict their functionality
and have them participate with UWWI? For example,
I’d like to prevent users from running certain applications like the registry
editor.
Almost all desktop restrictions are now controlled via group policy objects
(gpo). Computers can be grouped together either in an OU (you could setup an OU
under your primary OU or child domain) or in groups (just like users can be
members of groups). This makes it simple to apply a restrictive gpo to many
computers. You can either assign your restrictive group policy to your public
workstation OU, or you could assign the gpo to your entire OU (or child domain)
and only give the public workstation computer group the access rights to read
& apply it. The OU approach is cleaner, but there are other reasons to take
the group approach. As to what can be restricted . . . a lot. Windows has the ability to be quite restrictive. You can
prevent the command prompt from being called, restrict access to the task
manager, and either specify a “don’t run” list or the converse: give a list of
“only allow these programs to run.”
Many folks commonly use a product called Deep Freeze to keep a Windows computer
perpetually in a
known "frozen" state. Microsoft has a
Shared Computer Toolkit that can be used to implement quite a bit of restrictions
on shared computers. Finally, Nebula provides a kiosk model that may be appropriate;
contact help@u.washington.edu for
more details.
Go to top
of page
How can I remotely access my Windows computer?
One option is Windows file sharing. All Windows computers (from Windows 3.11
for Workgroups on) are capable of sharing files with other Windows computers.
This means that any networked Windows computer should be able to access a file
share on another Windows computer, if the user has the proper access permissions
to the file share. There are a few things you need to do to make it happen, and
several provisos that you should consider. Windows operating systems since Windows 2000 have file
sharing built in by default, whereas earlier Windows OS' need an additional
piece of software installed to enable this functionality. In a nutshell, one creates a
file
share, and then grants both share permissions and NTFS permissions to the appropriate
folks.
If the computer being used to access the shared resources is not part of a domain,
then you will need to specify a UWWI acccount after you attempt to access the file share. You'll get a login
challenge, for which you'd respond:
Connect As: netid\UW NetID
Password: UWNetidPassword
This assumes that the computer with the shared resources belongs to a domain that
trusts UWWI.
Another possible option is called Terminal Services or Remote Desktop, depending
on the Windows operating system. One uses a simple client software, called a RDP client or terminal
services client to remotely connect to the remote Windows computer.
The connection gives you an
identical graphical interface to your computer as if you were at the console.
There is one last option with Windows Terminal Services, which may be very
useful to people who travel and want to use an Internet café to access their
Windows computer. Awhile ago, Microsoft released the Terminal
Service Advanced Client, which contains an ActiveX control that Internet
Explorer on a Windows client can use to connect to a Terminal Server. By placing this ActiveX control on a webserver, you only need a browser, and a URL to a special webpage to be directed to your remote Windows
computer. There are more details about this functionality
on the Microsoft website.
Go to top
of page
How does name resolution work with Windows?
Windows NT clients used the following order for sources of name
resolution:
Local cache, hosts file, lmhosts file, B node broadcast (if client is a B
node) or WINS (if client is a P or H node), DNS. The
node type depends on network configuration.
Windows 2000 switches the last two and uses DNS before WINS. This is a key
difference, and reflects a tigher reliance on DNS. All Windows OSes since Windows 2000 have
retained this order of name resolution.
Reference documents:
Go to top
of page
How does browsing work with Windows?
You’ve probably noticed that “My Network Places” has an icon for “Entire
Network” as well as icons for common shares you visit, and you can add shortcuts
to urls or windows shares. The “Entire Network” icon is the equivalent of the
“Network Neighborhood” browse list you saw on previous Windows OS’.
Browsing is a wide and complex topic, so we can only cover the main points of interest.
See the
name resolution topic for some background.
B node broadcasts don’t go through routers, so
typically Windows NT domains with B nodes (i.e. workstations w/o any WINS server to
point to) have a truncated browse list featuring only those workstations
on the same side of the router as they were located. Additionally, master
browser election wars would frequently occur when more than one domain was on
the same subnet. All of this resulted in very confused users and frustrated
administrators. So with NT4, the “network neighborhood” list was created was via
a highly unreliable network of master browsers on each subnet.
Windows 2000 makes a small improvement to this situation. Now each Windows
2000 domain master browser (the DC with the PDC emulator role) actively queries
it's configured WINS server for a list of all registered domains. It uses this
list to contact the other domain master browsers to coordinate browser lists
with. This means that the browse list presented to the workstation should be
more complete than before. All workstations should be represented assuming that
the domain master browser of every domain (or workgroup) is configured to use a
central WINS server, and at least one workstation from every domain (or
workgroup) on each router segment is able to contact it’s domain master
browser.
But clearly, browsing is not a reliable mechanism for locating computers and we
don't recommend its use.
Reference documents:
Go to top
of page
I hate browse lists. Can I turn them off?
There are several ways to defeat the browsing behavior depending on what
approach you like:
There are gpo's which can replace the network neighborhood with a custom
list. This custom list could be empty or only have a few entries like relevant
servers.
You can turn off your local Computer Browser service. Your computer won't be
listed in any browse lists.
You can systematically turn off the Computer Browser service (by OU, domain,
or site-wide) via a gpo.
Turning off browsing is not “the answer” to making your machine/OU/domain
more secure.
Go to top
of page
What is a WINS server and is there a central service?
WINS stands for Windows Internet Name Service. A WINS server holds mappings
from a NetBIOS name (the name of your computer in the Network Control Panel) to
your computer's IP address. If you want other people to access your computer without
knowing the fully qualified DNS name
across subnets, then using the same WINS server
is the solution. Using a WINS server also helps improve the quality of the browse list seen in Network Neighborhood. DNS name resolution is superior, but requires
the person to type in a fully qualified DNS name in order to reference your computer.
Because the client resolution order for NT4 clients first checks for NetBIOS
resolution before DNS resolution, larger NT4 domains often opt to implement a
WINS server to improve domain performance. Windows 2000 clients use DNS
resolution before NetBIOS resolution. Windows 2000 clients version of the
Network Neighborhood, My Network Places, has an improved browse list (over NT4)
with a common WINS server implemented.
In the past, the UW has not supported WINS campus-wide. Some departments have
informally used the UW Technology WINS servers to avoid running WINS themselves. With the
advent of UWWI, these UW Technology WINS servers are considered part of the UW Windows Infrastructure
and supported as such. You do not need to be in a domain that trusts UWWI to use
these services. However, UW Technology only plans to provide WINS services as long as
needed to support UWWI. Microsoft has indicated it plans to
remove all reliance on NetBIOS resolution in future versions of Windows.
WINS support is required for domain migration. Common WINS servers for all machines in the domain
throughout the migration are very important to retain resolution.
The IP addresses for the centrally supported WINS servers are 140.142.1.6 &
140.142.13.229.
Go to top
of page
How does a cross-forest trust work?
A cross forest trust consists primarily of a
shared secret (associated with a trustedDomain object) between forests, and some
mapping information which enables DCs to refer requests with certain UPN or SPN
suffixes to the appropriate domain. See the section on cross forest logon for
more detail. Also of note is that in addition to the information needed to issue
Kerberos referrals, a forest trust can be leveraged like a downlevel trust (NTLM)
when needed.
Go to top
of page
What happens with global catalogs cross-forest?
Global catalogs are used in several ways to
make cross forest trusts work. Nothing that happens, though, is very exotic or
even new. In a user’s forest, an authenticating DC will contact a global catalog
to enumerate the user’s Universal group memberships, just as it would under
normal circumstances. In the case of a forest trust where the user then wants to
access a resource in the trusting domain- a Kerberos referral (containing these
same groups) is passed to the client, to be passed to a KDC in the resource
(trusting) domain. These groups are then combined (with or without nesting) with
any Domain Local groups that the user belongs to in the resource domain and so
the final service ticket issued by the resource domain KDC contains the user’s
Global and Universal groups from her own domain, and any Domain Local groups
from the resource domain. So we used a Global Catalog in this transaction, but
not in a new or interesting way. All we did was enumerate the user’s Universal
groups, which is what we always do during initial authentication.
The trustedDomain object that represents the
forest trust is also replicated to Global Catalogs. This allows DCs throughout
one forest to easily find routing (suffix) information to identify that a client
or service principal may be located in a forest across the trust.
Go to top
of page
What happens with group memberships cross-forest?
The same rules apply as with a
traditional (external) trusts as used in 2003. Global and Universal groups from
the account’s domain/forest can be added to local groups (domain and/or machine
local) in the resource domain. As always, you can skip the nesting and include
individual users, global, and universal groups from the account domain in ACLs
in the resource domain. The best practice, as it has been for years, is to add
accounts to global groups (generally following user type, properties or role),
combine global groups into universal if necessary, and then add those global or
universal groups to local groups (domain and/or machine local) close to the
resource. Therefore if the nature of Bob is that he is in the helpdesk (global
group), and he is a full time employee (global group) that is all you have to
manage, and those groups are members of domain local groups in any domain that
they need to be to grant access to resources (“HelpDesk” is a member of “Allowed
to Reset Passwords”, for example, and “Full Time Employees” is a member of
“General Access to HR Portal”). Of course you could skip all that and just add
users to ACLs but that gets messy. And now you’re bored. You already knew all of
this.
The short answer is that groups
work exactly how they worked before.
This
diagram shows the valid possibilities. Lines in blue indicate group
membership possibilities. Lines in red indicate ACL possibilities. Only the
Forest A-Domain X (AX) column shows all intra domain possibilities, the
interaction between AX and BY shows cross-domain plus cross-forest possibilities
and the interaction between BY and BZ shows cross-domain, intraforest
possibilities.
Go to top
of page
How does Group Policy and Logon Scripts work cross-forest?
Loopback processing is used by default for
users in cross forest logon, but normal processing can be enabled via the
(machine) Group Policy setting “Allow Cross Forest User Policy….” Also worth
noting is that with “Allow Cross Forest User Policy…” set, you can still use
loopback processing in either merge or replace mode, via the traditional means
of enabling loopback on a GPO that applies to the machine.
Go to top
of page
What is
the order of group policy processing?
Go to top
of page
How does the Windows Address Book work cross-forest? By default the “Active Directory” ‘account’
within the “Find People” applet searches the workstation’s forest. This can be
configured to search any arbitrary LDAP provider, including the user’s forest,
by modifying the properties of the “Active Directory” ‘account’, or by creating
a new ‘account’ to search the desired directory.
These providers or accounts appear to be stored
in HKEY_CURRENT_USER\Software\Microsoft\Internet Account Manager\Accounts so if
you wanted to automate this configuring this, you could use a logon script to do
it.
Go to top
of page
Is SID Filtering relevant to forest trusts?
Yes. SID filtering is available on forest
trusts, and does not appear to be on by default. It can be configured using:
netdom trust <trustingdomain> /D:<trusteddomain>
/quarantine [yes|no]
Because sid filtering allows only SIDs from the
trusted domain to carry over into the trusting domain, it appears that it can
break the transitivity of a forest trust.
For example, if you had two forests with a
forest trust between the forest root domains, and you expected a SID from a
child domain in one forest to be usable in the other forest, this fails if SID
Filtering is enabled.
Go to top
of page
On which DCs does auditing occur? i.e. when I log in, what security events are
logged where?
The general rule, which still
applies here, is that “Account Logon” events are logged at the
authority for the account, and regard events relevant to the authority for the
account (such as password verifications). One the other hand “Logon” events are
related to creating a security context on a particular machine- by building an
LSA access or impersonation token in order to access a resource, and so are
logged on the target/resource machine.
For example, a bad password attempt is audited
on the authenticating DC (and the PDC in the case of a bad password, since it
double checks with the PDC) as an Account Logon (Failure) event. See the
following screenshot:
One thing to watch out for when looking for
Account Logon events in the Security log is that the “User Name” column in Event
Viewer will generally just be “SYSTEM” (there is no security context for the
user on the server yet), while the real username in the request is included in
the data payload of the event.
A successful password verification (AS
exchange, if using Kerberos), is logged on the authenticating DC as follows:
Once the initial verification has taken place,
we immediately start getting service tickets in order to build LSA tokens to
access the machine we are logging on interactively to, as well as network
resources (for example we immediately start accessing authenticated LDAP and SMB
on a DC in order to apply Group Policy).
You can audit the service tickets themselves
from the KDC, and you can audit these Logon events on any machine where the user
has an LSA token built. An example Logon event follows:
Note that the logon type is “3” which is a
network logon (This was logged on a DC while the client was applying Group
Policy). Examples of type 3 logons are SMB, LDAP, IIS with integrated auth, etc.
From an administrative perspective, this corresponds to the “Access this
computer from the network” user right. These logon related user rights are the
first piece of authorization that happens after authentication. A special SID
representing the logon type is also injected into the final token, in case the
system or applications need to make authorization decisions based on the logon
type, in addition to group memberships.
On the workstation being logged on to
interactively, we would expect to see a Logon event with a type 2 (Normal,
Interactive) and/or type 11 (Cached Interactive). On a default XP configuration
with access to the domain you will actually see both type 2 and type 11 logons
during an interactive logon, because XP tries to log you on asynchronously to
save time. Basically XP checks your cached credentials first, and if successful
it already starts to build your windows station and gets a jump start on running
userinit.exe and explorer.exe. Simultaneously, it goes out to the domain for
authentication and group policy, etc. This is why it is generally much faster to
get to a desktop in XP than it was in 2000 Professional, and it results in the
mix of type 11 and type 2 Logon audits. This “fast logon optimization” behavior
can be disabled via the Group Policy “Computer Config > Adm > System > Logon >
Always wait for the Network…” The advantage of “fast logon” is that you may
reach a Ctl+Alt+Del screen much sooner after booting, and reach a desktop sooner
after providing credentials. The down side is that because of the cached
credentials it can sometimes take more than one reboot and/or logon before local
LSA tokens reflect changed group memberships, and for certain actions (like
folder redirection) which require exclusive access to a resource to take place.
Because of this, many administrators disable this behavior entirely or at least
during changes and troubleshooting. This behavior is also disabled (for the user
side, at least) under certain user conditions (no cached credentials present,
for example). See KB article 305293.
Two of the several logon events registered when
logging on interactively to an XP machine (with Logon: Success) with auditing
enabled follow:
For great information about token building, logon types,
and auditing, see the following:
Token Building (also see related pages in left hand pane).
Note that the graphic about getting groups from the DCs is a high level
abstraction, and is not specific to Kerberos. The paragraph after the graphic
clears this up.
http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/TechRef/d06a5070-2a7b-4e75-b7e9-ebe51f65e34b.mspx
Logon Events and Logon types
http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/ServerHelp/e104c96f-e243-41c5-aaea-d046555a079d.mspx
Account Logon events
http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/ServerHelp/d8fc798c-1e77-4043-b59c-971b4961d85a.mspx
For error codes seen in Account Logon Failure events
(675s), see the following (about a third of the way down)
http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/TechRef/b36b8071-3cc5-46fa-be13-280aa43f2fd2.mspx
You can also audit other authentication related happenings,
for example the issuing of service tickets, and NTLM passthrough authentication,
to customizable degrees of verbosity.
For auditing and logging options on the KDC, see the
following doc (same one as above, but about ¾ through the doc). You’ll want to
reference the entire registry section as there are a variety of options of
Kerberos client and KDC logging to the event logs, and also sending verbose
information to DbgPrint which can be captured in a debugger, or in a tool like
dbgview.exe from sysinternals.
http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/TechRef/b36b8071-3cc5-46fa-be13-280aa43f2fd2.mspx
For verbose logging of Netlogon, which is responsible for
NTLM passthrough authentication, see the following KB. This is useful (along
with Account Logon: Failure events) for identifying hosts which are infected
with worms that try to brute force account passwords, thereby locking out
(potentially many) accounts.
http://support.microsoft.com/?id=109626
Go to top
of page
How does the selective auth functionality work & is it useful for us?
Selective authentication is just a
mapping, which could be thought of as an additional filter layer in the KDC’s
internal logic, which limits what clients may be granted service tickets to
certain resources. It is worth noting that authentication does not imply
authorization, so resources are still secured in their usual manner (NTFS
permissions for files, various internal authZ models for apps, etc). Selective
authentication just adds an additional layer of protection and selectivity,
whereby client principals aren’t even allowed to “introduce themselves” to
service principals unless specifically allowed for in the selective
authentication mapping. See the
technet description for more info.
Go to top
of page