Win 2000 login

[cRazEYgUy]

Hi guys,

This is my first post and this might be one for the experts. The system admins at my work recently updated all of our machines. I was informed by the tech support that to logon to the computers now, you had to get an access ID/password assigned to you.

So this is what I saw. After CTRL-ALT-DEL is pressed, a customised logon screen is displayed. I'm assuming this is the nd_gina.dll file. After the user ID and password are entered, the computer logs in.

The user IDs and passwords are not stored locally on the machine, because there are over 200 ids/passwords. I also know for a fact that SQL server is used somehow to validate the user account. (I asked about all of this while they were setting it up).

My question is, how does all of this work together? How is the ID/pass sent to the remote SQL server and what program actually sends it? Is it the gina file that is sending the query to the SQL server to validate the account or is it something else?

This might be kind of confusing, so ask if something is unclear. Thanks in advance for any help!

EDIT: I also know for a fact that a separate windows account named SqlAgentCmdExec is used somehow. I did some research on this and I think this is the account that has permissions to run queries on the remote SQL server to check whether the ID/pass is valid.

Edited August 28, 2004 by cRazEYgUy

[Tel]

In my limited knowledge I would imagine that when Windows authenticates the user ID/pwd the server is set up automatically to check in the SQL. I don't know how though.

[Marsden]

I seriously doubt SQL is used to authenicate User IDs and Passwords. Sounds more like a Domain Controller with Active Directory.

User Authentication

User authentication confirms the identity of any user trying to log on to a domain or access network resources. Win2K authentication enables single sign-on to all network resources. A user can log on to the domain once, using a single password or smart card, and can then access resources on any computer in the domain. For users, single sign-on provides quick and efficient access to resources. For administrators, single sign-on reduces the amount of support required for users because the administrator needs to manage only one account per user.

Win2K user authentication, including single sign-on, is implemented as a single, two-part process: interactive logon and network authentication. Successful user authentication depends on both parts of this process. The first two subsections briefly describe these two aspects of authentication. The third subsection describes authenticating external users:

• Interactive logon

• Network authentication

• Using certificates to authenticate external users

For detailed technical descriptions of Win2K user authentication, see the Windows 2000 Resource Kit "Authentication" chapter listed in "For More Information."

Interactive Logon

Interactive logon (the first part of the single sign-on process) confirms the user's identity to the user's Active Directory domain account or local computer. When a user walks up to the computer to start work, the user logs on, that is, presents credentials (domain or local) to the computer to gain access to its resources (monitor, keyboard, mouse, local disk, network access, and so on). This process differs depending on the type of user account:

• Domain account. With a domain account, a user logs on to the network (with a password or smart card) using single sign-on credentials stored in Active Directory. After logging on with a domain account, an authorized user can access resources in the domain and any trusting domains.

• If a password is used to log on to a Win2K computer using a domain account in a Win2K domain, Win2K uses Kerberos version 5 (V5) for authentication. If a smart card is used instead of a password, Win2K uses Kerberos V5 authentication with certificates.

• If the authenticating domain controller is a Windows NT 4.0 domain controller or if the user's computer is a Windows NT 4.0 computer, then the authentication used is Windows NT LAN Manager (NTLM). (See next section for more about Kerberos and NTLM.)

• Local account. With a local computer account, a user logs on to a local computer using credentials stored in that computer's Security Accounts Manager5 (SAM), which is the Win2K local security account database. Any Win2K computer that is not a domain controller can store local user accounts, but those accounts can be used for access only to that local computer.

Network authentication (described next) is transparent to users using a domain account. When using the domain account, the user's credentials are used for a single sign-on. Users using a local computer account, however, must provide credentials (such as a user name and password) each time they access a network resource.

Network Authentication

Network authentication (the second part of the single sign-on process) confirms the user's identity to any network service the user attempts to access. For network authentication, Win2K uses one of the following industry-standard types of authentication:

• Kerberos V5 authentication. Kerberos V5, the default method of network authentication for services for computers running Win2K server or client software, is the primary security protocol for authentication within Win2K domains. Based on Internet standard security, Kerberos V5 authentication is used with either a password or a smart card for interactive logon. Kerberos provides fast, single logon to Win2K Server-based resources, as well as to other environments that support this protocol.

The Kerberos V5 protocol verifies both the identity of users and of network services. This dual verification, called mutual authentication, takes place between a client and server—the server verifies the client identity, and the client verifies the server's identity. Kerberos replaces NTLM (see next subsection) as the primary security protocol for access to resources within or across Windows 2000 Server domains. If any computer involved in a transaction does not support Kerberos V5, the system uses the NTLM protocol.

The Kerberos V5 authentication mechanism issues tickets for accessing network services. A ticket, issued by a domain controller, is a set of identification data for authenticating a security principle. Tickets contain encrypted data (including an encrypted password) that confirms the user's identity to the requested service. Except for entering a password or smart card credentials, the Kerberos authentication process is invisible to the user.

• Windows NT LAN Manager (NTLM) authentication. NTLM authentication also provides network authentication within Win2K domains. In Win2K, NTLM is used as the authentication protocol for transactions between two computers in a domain, where one or both computers is running Windows NT 4.0 or earlier. (Recall that by default, Win2K is installed in a mixed-mode network configuration—that is, a configuration that uses any combination of Windows NT 4.0 and Win2K.) NTLM is used when either the client or server uses an earlier version of Windows. That is, computers with Windows 3.x, Windows 95/98, as well as Windows NT Workstation 4.0 use the NTLM protocol for authentication in Win2K domains. NTLM is also the authentication protocol for computers not participating in a domain, such as standalone servers and workgroups.

• Secure Sockets Layer/Transport Layer Security (SSL/TLS) authentication. SSL/TLS provides authentication when a user attempts to access a secure Web server. SSL/TLS consists of four operations:

• Handshake and cipher suite negotiations. Client and server contact each other and choose a common cipher suite. The suite includes a method for exchanging the shared secret key; a method for encrypting data; and a Message Authentication Code (MAC) specifying how application data will be hashed and signed to prove integrity.

• User identity authentication. The server always authenticates its identity to the client. However, whether the client needs to authenticate with the server depends on the application. The exact authentication method (primarily, which digital certificate format will be used) depends on the negotiated cipher suite.

• Key exchange. After choosing a cipher suite, the client and server exchange a key, or the precursors with which to create a key, that they will use for data encrypting (again, depending on the negotiated cipher suite's requirements).

• Application data exchange. The client application and the server application communicate with each other. All data is encrypted using the negotiated bulk encryption method.

Using Certificates to Authenticate External Users

Organizations must often support authentication of external users, individuals who do not have an account in Active Directory. Examples of when you may want to provide external users with secure access to specific data within the enterprise include corporate partners who need extranet access, a department that needs access to another department's intranet pages, or part of the public to whom you may want to provide selective access.

Active Directory supports external user authentication. To authenticate external users, you must do the following:

• Use a certificate. The external user must have a certificate. A certificate is a file used for authentication and secure exchange of data on nonsecured networks, such as the Internet. A certificate securely binds a public key to the entity that holds the corresponding private key held by the individual. Certificates are digitally signed by the issuing certification authority (CA) and can be managed for a user, a computer, or a service.

The external user's certificate must be issued by a CA that is listed in the certificate trust list for (or trusted by) the Active Directory site, domain, or organizational unit in which you have created the user account.

• Create a user account. You must establish a user account (for use by one or more external users).

• Map the certificate to the account. You must create a name mapping between the external user certificate and the Active Directory account you have created for authenticated access.

Any external user whose client program presents a mapped certificate can then access the permitted locations published on the appropriate Web site for your organization. The authentication process is transparent to the external user.

User Authorization

Besides confirming the identity of anyone attempting to access the network (user authentication, described in the preceding section), a good security system also protects specific resources—such as payroll data—from access by inappropriate users.

Active Directory secures resources from unauthorized access. From the standpoint of the user, controlling access to resources, or objects, on the network is called user authorization. From the standpoint of the object being protected, it is called object-based access control. Once a user account has received authentication and can potentially access an object, the type of access granted is determined by either the user rights that are assigned to the group (or user) or the access control permissions that are attached to the object.

This section covers these topics in the following subsections:

• User rights: Assigned to groups

• Access control permissions: Attached to objects

User Rights: Assigned to Groups

As an administrator, you can assign specific user rights to group accounts or to individual user accounts. You can think of them as user or group rights, rather than as simply user rights, because typically you assign rights to a group rather than to an individual user. There are two types of user rights:

• Privileges. For example, the right to back up files and directories.

• Logon rights. For example, the right to logon locally.

Note: Strictly speaking, logon rights, which refer to the local computer, do not belong in a discussion of Active Directory.

User rights are different from permissions (described next) because user rights apply to user accounts, whereas permissions are attached to objects.

Although user rights can apply to individual user accounts, to simplify the task of account administration user rights are best administered on a group account basis. It is easier to assign the set of user rights once to the group, rather than repeatedly assigning the same set of user rights to each individual user account. To remove rights from a user, you remove the user from the group.

Certain privileges can override permissions set on an object. For example, a user logged on to a domain account as a member of the Backup Operators group has the right to perform backup operations for all domain servers. However, this requires the ability to read all files on those servers, even files on which their owners have set permissions that explicitly deny access to all users, including members of the Backup Operators group. A user right, in this case, the right to perform a backup, takes precedence over all file and directory permissions.

For a complete list of user rights (both privileges and logon rights), see "Appendix B: User Rights."

Access Control Permissions: Attached to Objects

Access control is the process of assigning permissions to access Active Directory objects.

You can assign permissions for objects to the following:

• Groups, users, and special identities in the domain

• Groups and users in that domain and any trusted domains

• Local groups and users on the computer where the object resides

Understanding access control permissions requires understanding the following interrelated concepts:

• Security descriptors

• Object ownership

• Object auditing

• Object permissions and inheritance

Security Descriptors

Win2K implements access control by allowing administrators or owners of objects to assign security descriptors to objects stored in Active Directory (or to other types of objects). A security descriptor is a set of information attached to an object (such as a file, printer, or service) that specifies the permissions granted to different groups (or users), as well as the security events to be audited. For example, for the file temp.dat, you might grant Read, Write, and Delete permissions to the Administrators group, but assign only Read and Write permissions to the Operators group.

For Active Directory objects, in addition to controlling access to a specific object, you can also control access to a specific attribute of that object. For example, you can grant a user access to a subset of information, such as employees' names and phone numbers, but not grant access to the employees' home addresses.

Each security descriptor for an object in Windows 2000 contains four security components:

• Owner. By default, the owner is the creator of the object, except for objects created by an administrator, in which case "Administrators" is the owner.

• Discretionary Access Control List (DACL). As explained in the Introduction, the DACL (often referred to as ACL) is a list of specific groups, user accounts, and computers that are allowed or denied access to an object. To change a DACL, a permission called WRITE_DAC is required.

• System Access Control List (SACL). As explained in the introduction, the SACL specifies which events are to be audited for which user or group. Examples of events you can audit are file access, logon attempts, and system shutdowns. To read or change the SACL, the SeSecurityPrivilege is required.

• Group (for POSIX). The Group component is for POSIX compliance and is associated with the "primary group" set in individual user objects in User Manager. (POSIX is based on the UNIX operating system, but it can be implemented by other operating systems.)

Each assignment of permissions to a group (or user) is known as a permission entry or access control entry (ACE). An ACE is an entry in an access control list (DACL or SACL). The entry contains a SID and a set of access rights. A process (running on behalf of a user) with the user's access token that has a matching security ID is either allowed access rights, denied rights, or allowed rights with auditing. The entire set of permission entries in a security descriptor is known as a permission set. Thus, for the file temp.dat in the example above, the permission set includes two permission entries: one for the Administrators group and one for the Operators group.

Because the Active Directory security model associates a DACL and SACL with each of its containers, objects, and object attributes, administrators can protect their network from intentional hostile acts by attackers and inadvertent mistakes by users.

Permissions can be applied to any object in Active Directory or on a local computer, but, for simplicity of administration, it is important to understand that the majority of permissions should be applied to groups, rather than to individual users.

[prathapml]

Hi crazeyguy, and welcome to the MSFN forums.

We all did initally register when we wanted to learn something - so its all good! You can be sure that there will be no shortage of people willing to help you. Can I suggest that you take a look at the documentation available in MS's own technet (regarding this subject) as well, since they have lots of things mentioned in great detail which may not be possible here.

http://www.microsoft.com/technet/default.mspx