Search This Blog

Feb 3, 2005

seemingly simple, namely "stupid", but hard-to-find-answer questions for beginners.

=========================================

More than often I was confused by a very basic concept that may be too simple for a guru but I just couldn't find a definite/clear answer ANYWHERE, and it slowed down my learning progress a lot. So, I am listing a few below, hoping that can help others who are experiencing similar problems.

1. do I have to have a MX record on my internal DNS for Exchange servers?
Answer: no. You don't. MX record is used only for people from Internet sending email to your organization.

2. Local Administrator, Domain Administrator, Administrators, and Domain Admins
1). "Administrator" is a built-in account that you can't disable/delete but can rename
2). If you are in a domain, you will have both "domain\administrator" and local "computer$\administrator" account. The one you see in Active Directory Users and Computers is domain administrator, while the one you see in Local Users and Groups is local Administrator. Note: on a Domain Controller, there is not Local Users and Groups anymore, and you will use only the one you see in ADUC, which is domain administrator (having local administrator permissions at the same time)
3). "Administrator" is not the same as LocalSystem
4). "Administrators" is a built-in local group for local administrators. "Domain Admins" is a built-in group for domain administrators.
5). By default, member of "domain admins" is also member of local "administrators"
6). You can put any one into "domain admins" and "administrators", they then get the permissions respectively

Feb 2, 2005

what is userenv.dll?

When you are troubleshooting logon or Group Policy issues, you will very likely see event ID coming from userenv in your system log. What is userenv then?

Userenv.dll is a the Group Policy Engine that applies policies to your computer and your account. It calls different client-side extension to process different portion of your group policy. The most common CSE's include registry(administrative templates), security templates, folder redirection, software restriction, and so on.

Each CSE has a corresponding DLL to process the settings except registry CSE, which is process by userenv.dll itself.

If there is something wrong with your Group Policy application, possible causes include name solution not working, AD replication broken, FRS replication broken, and/or permission issue, you are very likely to see error reported from source "userenv" in Application Log.

To troubleshoot this kind of error, besides reviewing Event Viewer and collecting other basic information, most of the time you will need to enable User Environment debugging level to get more details.

Key: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon Value: UserEnvDebugLevel
Value Type: REG_DWORD
Value Data: 10002 (Hexadecimal)

Jan 28, 2005

Kerboros Authentication in Windows 2000/2003 Environment
===============================================

logging on
=========
1. both DC and workstation use the same one-way algorithm to encrypt authenticator
2. user logs on workstation, the workstation composes two authenticators, one un-encrypted, one encrypted by the algorithm in step 1 using typed password as a key
3. workstation sends these two authenticators to DC
4. DC descrypts the encrypted authenticator, if the user has typed in a correct password in step 2, then DC will have a decrypted version of authenticator that is the same as the other copy sent by workstation in step 3
5. now the DC checks the timestamp against its authenticator history list, if it finds a match, then the log on is rejected
6. DC generates two TGTs that contain session key. One TGT is encrypted with a user's encrypted passwod, the other encrypted by DC's private key. TGT contains this user's Security Token(user's SID and its group's SID's)
7. DC sends two copies of encrypted TGTs to workstation, workstation stores both in non-paged pool memory
8. log on process finishes

Accessing Resources
==============
9. user/workstation wants to access a resource on another server
10. workstation gets the session key from TGT
11. workstation generates a "request ticket", encrypts it with session key
12. workstation sends the encrypted request ticket (from step 11) to KDC
13. workstation also sends a TGT back to KDC, KDC decrypts TGT with its own private key to get the session key from TGT
14. KDC now can use session key to decrypt the request ticket
15. KDC generates a new ticket (two copies) that contains the user's Security Token and a random key. one is encrypted with session key, the other is encrypted with the resource server's password (let's call them Access Ticket)
16. KDC sends two copies of new tickets back to workstation.
17. workstation decrypts one copy by using session key, and gets the random key(from step 15)
18. workstation composes a Resource Request, encrypts it with the random key
19. workstation then sends the other Access Ticket and the Resource Request to the target serverNote. because only the target server knows the password to decrypt the Access Ticket, the client is assured of a connection to its intended server. this is another advantage of Kerboros
20. the resource server uses its own password to decrypt the Access Ticket, gets the random key from Access Ticket
21. the resource server uses the random key to decrypt the Resource Request
22. the resource server process the Resource Request normally (checking the permissions against the Security Token)
Additional Reading
============
TechNet Home>Products&Tech>Server Operating Systems>Windows 2000 Server>Deploy>Configure Specific Features>Windows 2000 Kerberos Authentication
An very good article includes not only windows-specific kerberos info, but also a general briefing of how Kerberos was developed/why it's developed this way