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.

Where is your XP CD?

Yes you need Exchange 2003 installed on a server. I use it all the time while on the road. I just type in https://xx.xxx.xx.xxx/exchange and I get a nice secure pop up window for a secure logon... It looks like the real deal but runs in IE. I can do just about everything from the OWA client.

Get rid of this Symantec AV Control for Exchange crap... You want to use programs that work and not screw your system to hell.

Have you looked in Group Policy? Everything you need is there...

Have you tried Disk Management under Computer Management?

Administrative Tools>> Active Directory Domains and Trusts>> Select your production Domain. Right click on it and select Properties. Select the Trusts tab. Create a New Trust between your production domain and your new domain.

So you can show us all how to Sign-in and download all these publically available downloads... Or are we bound by this: What is the general nature of the terms of the MSDN End User License Agreement? The MSDN End User License Agreement (EULA) allows each person with an MSDN license to use all of the software that is included in the subscription for development, test, and demonstration purposes only. MSDN subscriptions are single-user licensed; everyone who uses the products within an MSDN Subscription must have an MSDN Subscriptions license. In other words, one license must be purchased for each user. Customers do not have to purchase media for each licensed user. MSDN subscription media can be shared with all individuals who have an MSDN Subscriptions license of the same level or higher. Note: The MSDN Library is an exception; it is not a single-user license and can be freely shared within an organization. You need to purchase the MSDN Library, but the information on the Library is available for use by anyone in your organization.

XP Home comes either in a Retail package or in 3-packs in an OEM package. I'm holding the Microsoft 2004 Product Guide that all OEM builders are given... there never has been a VLK for XP Home. That does not mean that some folks might try to market or sell a Home VLK but if they do it is not legit...

X64 64bit drivers are beta as well as x64 Windows... Give it time or find someone who has 64 bit hard up and running with X64 windows.

Take your pick... neither has enough memory to do an adequate job. I guess put the FTP on #2.

We have ordered our new Maxtors... should be in next week. We edit video... Maxtor DiamondMax 10 hard drives, integrated, single-chip native SATA solution, the new DiamondMax 10 drives feature native command queuing (NCQ), dual-processor technology, and a new 16MB buffer to deliver unparalleled speeds compared to traditional 7200 RPM drives. The drives self-balance system workloads for more efficient hard drive operations. They are going into RAID 5 arrays and will kick a** as compared to SCSI crap... We are using 3ware's Escalade 9500Ses. We have tested production samples of the Maxtor 350 GB drives in excess of 400 Mbytes per second (MB/sec) sustained RAID 5 reads and over 100 MB/sec RAID 5 sequential writes with less than 3% CPU utilization.

I answered this question on <<spam>>... look it up...

You had to have installed it on a different partition, otherwise Win2K3 would have over written all the XP files. Find the location of Win2K3 and delete the files and folders. Edit your boot.ini and remove the entry for Win2K3.

Put Exchange on Server 1. 2+3 don't have enough memory for Win2K3 Server and Exchange 2003. 1+2 should be RAID 5 3 should be RAID 0

You need 64bit drivers for X64 Windows... 32bit drivers will not work...

YES

You are using an Office XP Enterprise Version.... Please give more info...

Not really... the Express installer is 1.6 Megs and the "package" you get varies on how current your patched SP1a was or is. The 270 MBs only applies to the Network Install Package...

No... There is nothing you can do. Patience... you will eventually get SP2...

So schedule the Disk check the next time you reboot... it's no big deal. 2003 is protecting itself from you...

Boot from your CD and select the 2nd Repair Option otherwise known as an Upgrade in Place. Select your install directory and your systems files will be replaced with the orginals from the CD. Your Registry and all settings will be untouched. Apply all patches and Services Packs when setup has completed.

Check the Windows Server 2003 HCL (Hardware Compatability List)

Actually, Pocket PC with USB 2.0...

You are not getting the drivers from the floppy disk you need. Bad disk or bad drive... Means bad media or bad delivery of data... If you are having trouble with the CD disks your drive may be dirty or dying... swap it out as well. Especially, if two different disks are having the same problem...