Windows Server 2008

The default tombstone lifetime is 60 days for forests initially built using Windows 2000 and Windows Server 2003, and 180 days for forests that were initially built with Windows Server 2003 SP1. You can change the tombstone lifetime by setting the tombstoneLifetime attribute of the CN=Directory Service,CN=Windows NT, CN=Services,CN=Configuration, DC=<root domain> object. Every 12 hours, each domain controller starts a garbage collection process. (This can be changed by setting a new value for the garbageCollPeriod attribute of the CN=Directory Service,CN=Windows NT, CN=Services,CN=Configuration,DC=<root domain> object.) This garbage collection scans all of the tombstones on the DC and physically deletes any that are older than the tombstone lifetime.

Date and Time control panel

Windows Server 2008 Active Directory Lightweight Directory Services (AD LDS)Function:

By using the Windows Server2008 Active Directory Lightweight Directory Services (AD LDS) role, formerly known as Active Directory Application Mode (ADAM), you can provide directory services for directory-enabled applications without incurring the overhead of domains and forests and the requirements of a single schema throughout a forest.

In the following sections, learn more about the AD LDS server role, the features in it, and the software and hardware considerations for installing it.

What is the AD LDS server role?

AD LDS is a Lightweight Directory Access Protocol (LDAP) directory service that provides flexible support for directory-enabled applications, without the dependencies that are required for Active Directory Domain Services (AD DS). AD LDS provides much of the same functionality as AD DS, but it does not require the deployment of domains or domain controllers. You can run multiple instances of AD LDS concurrently on a single computer, with an independently managed schema for each AD LDS instance.

AD DS provides directory services for both the Microsoft Windows Server server operating system and for directory-enabled applications. For the server operating system, AD DS stores critical information about the network infrastructure, users and groups, network services, and so on. In this role, AD DS must adhere to a single schema throughout an entire forest.

The AD LDS server role, on the other hand, provides directory services specifically for directory-enabled applications. AD LDS does not require or rely on Active Directory domains or forests. However, in environments where AD DS exists, AD LDS can use AD DS for the authentication of Windows security principals.

When should I use the AD LDS server role?

The following sections describe common AD LDS enterprise directory solutions.

Providing an enterprise directory store

AD LDS is a full-fledged LDAP directory solution for enterprises. All directory-enabled enterprise applications can use AD LDS as their directory store.

AD LDS can store "private" directory data, which is relevant only to the application, in a local directory service-possibly on the same server as the application-without requiring any additional configuration to the server operating system directory. This data, which is relevant only to the application and which does not have to be widely replicated, is stored solely in the AD LDS directory that is associated with the application. This solution reduces replication traffic on the network between domain controllers that serve the server operating system directory. However, if necessary you can configure this data to be replicated between multiple AD LDS instances.

Enterprise applications must often store personalization data that is associated with authenticated users in AD DS. Storing this personalization data in AD DS would require AD DS schema changes. In this scenario, an application can use AD LDS to store application-specific data, such as policy and management information, while it uses the user principals in AD DS for authentication and for controlling access to objects in AD LDS. Such a solution makes it unnecessary for each AD LDS directory to have its own user database. Therefore, this solution prevents a proliferation of user IDs and passwords for end users every time a new directory-enabled application is introduced to the network.

Providing an extranet authentication store

Consider the example of a Web portal application that manages extranet access to corporate business applications and services identities that are external to the corporate AD DS. Another example might be a hosting scenario in which a provider offers domain and storage services to its customers by maintaining and updating customer-dedicated Web or data servers, with no customers having access to these servers.

These servers and portal applications that are deployed in an extranet have custom identity needs. They require an authentication store to save authorization information for the identities that they service. AD LDS is a good candidate for this authentication store because it can host user objects that are not Windows security principals but that can be authenticated with LDAP simple binds. In other words, Web clients can be serviced by portal applications that can run on any platform while they use AD LDS as a simple LDAP authentication store.

If a portal application that you deploy in an extranet must service internal AD DS-authenticated identities that are currently located outside the corporate firewall, you can still deploy AD LDS as the authentication store with the corporate account credentials of these identities provisioned on the extranet instances of AD LDS, as shown in the following illustration.

Providing an extranet authentication store.

You can also deploy AD LDS as an extranet authentication store along with Active Directory Federation Services (AD FS). This configuration enables Web single-sign-on (SSO) technologies to authenticate users to multiple Web applications with a single user account.

Consolidating identity systems

You may have a scenario in which a data model restriction, such as a single LDAP partition view or a single organizational unit (OU) view, is imposed on an enterprise directory-enabled application that must access data that is associated with AD DS-authenticated users, applications, or network resources that are located in multiple forests, domains, or OUs in the enterprise. Identity information for this directory-enabled application must be consolidated from multiple Active Directory forests, domains, and OUs or from multiple identity systems and other directories, such as human resource databases, SAP databases, telephone directories, and so on.

AD LDS offers a consolidating directory solution because you can deploy it along with a metadirectory. Metadirectories, such as Microsoft Identity Integration Server (MIIS) or Microsoft Identity Integration Feature Pack (IIFP)-which is a free, lightweight version of MIIS, can provide directory-enabled applications with a unified view of all known identity information about enterprise users, applications, and network resources by performing identity integration, directory synchronization, account provisioning and deprovisioning, and password synchronization between AD DS and AD LDS, as shown in the following illustration.

Consolidating identity systems.

Providing a development environment for AD DS and AD LDS

Because AD LDS uses the same programming model and provides virtually the same administration experience as AD DS, it can be a good fit for developers who are staging and testing various Active Directory-integrated applications. For example, if an application under development requires a different schema from the current server operating system AD DS, the application developer can use AD LDS to provide the application with a tailored schema that works for business needs, data requirements, and workflow processes, without altering the configuration of the corporate Active Directory deployment. Developers can work with an AD LDS instance without the need for a complicated setup and later move the application to AD DS. Developers may want a directory that they can easily program to without requirements for extensive setup or hardware support during the development process. This can be achieved through AD LDS as it can easily be installed and uninstalled on any Windows Server 2008 computer. This allows rapid restoration to a clean state during the application prototyping and development process.

Providing a configuration store for distributed applications in Windows Server

You may have a distributed application that requires a configuration store with multimaster update and replication capabilities to service its multiple components, for example, a firewall application that accesses network and application ports data, a junk mail filtering application that accesses e-mail address lists, or a workflow application that accesses enterprise and policy data. You can deploy AD LDS as a lightweight configuration store for such applications, as shown in the following illustration.

Providing a configuration store for distributed ap

In this scenario, an AD LDS instance that serves as the application's configuration store is bundled with a distributed application. This way, application designers do not have to be concerned about the availability of a directory service before the installation of the application. Instead, they can include AD LDS as a part of their application's installation process to ensure that the application has access to a directory service immediately upon installation. The application then configures and manages AD LDS entirely on its own or partially, depending on the application's exposure to the AD LDS management, and it uses AD LDS to address its various data requirements.

Migrating legacy directory-enabled applications

Your organization may use an already established directory with X.500-style naming (O=<organization>,C=<country>) to serve various legacy applications, but it may also want to migrate its enterprise directory to AD DS. In this scenario, you can use AD LDS as an interim solution. You can deploy AD LDS to serve and provide support for the legacy applications that rely on X.500-style naming, while you can use AD DS in the enterprise to provide a shared security infrastructure. You can use a metadirectory, such as MIIS, to automatically synchronize the data in AD DS and AD LDS for a seamless migration experience. The following illustration describes this AD LDS deployment.

Migrating legacy directory-enabled applications.

Features in the AD LDS server role

You can use the AD LDS server role to create multiple AD LDS instances on a single computer. Each instance runs as a separate service in its own execution context. The AD LDS server role includes the following features to make it easy to create, configure, and manage AD LDS instances:

* A wizard that guides you through the process of creating an AD LDS instance

* Command-line tools for performing unattended installation and removal of AD LDS instances

* Microsoft Management Console (MMC) snap-ins for configuring and managing AD LDS instances, including the schema for each instance

* AD LDS-specific command-line tools for managing, populating, and synchronizing AD LDS instances

In addition to these tools, you can also use many Active Directory tools to administer AD LDS instances.

The Windows Server 2008 operating system includes the additional AD LDS features in the following table.

Feature Description

Install from Media (IFM) Generation

With this feature, you can use a one-step Ntdsutil.exe or Dsdbutil.exe process to create installation media for subsequent AD LDS installations.

Audit AD LDS changes

With this feature, you can set up AD LDS auditing with a new audit subcategory to log old and new values when changes are made to objects and their attributes.

noteNote

This feature also applies to AD DS.

Data Mounting Tool

With this feature, you can view directory data that is stored online in snapshots that are taken at different points in time to better decide which data to restore, without having to restart the server.

noteNote

This feature also applies to AD DS.

Support for Active Directory Sites and Services

With this feature, you can use the Active Directory Sites and Services snap-in to manage replication among AD LDS instances. To use this tool, you must import the classes in MS-ADLDS-DisplaySpecifiers.LDF to extend the schema of a configuration set that you want to manage. To connect to an AD LDS instance that hosts your configuration set, specify the computer name and the port number of a server that hosts this AD LDS instance.

Dynamic list of LDAP Data Interchange Format (LDIF) files during instance setup

With this feature, you can make custom LDIF files available during AD LDS instance setup-in addition to the default LDIF files that are provided with AD LDS-by adding the files to the\ADAM directory.

Recursive linked-attribute queries:

With this feature, you can create a single LDAP query that can follow nested attribute links. This can be very useful in determining group membership and ancestry.

In the Windows Server 2008 R2 operating system, AD LDS includes the following new features (also available for AD DS in Windows Server 2008 R2) that help improve its manageability and supportability:

* Active Directory Recycle Bin: Enhances your ability to preserve and recover accidentally deleted Active Directory objects.

* Active Directory PowerShell: Provides command-line scripting for administrative, configuration, and diagnostic tasks, with a consistent vocabulary and syntax.

* Active Directory Web Services: Provides a Web service interface to Active Directory domains, AD LDS instances, and Active Directory Database Mounting Tool instances.

To open an adt file, you must use an advantage database driven application, server or utilities.

.adt file=Advantage database file.

Advantage database by Sybase.

Desktop Experience

With Hyper-V, a virtual machine runs in the background until you connect to it with Hyper-V Manager. A running VM doesn't require using Hyper-V Manager, nor does it require anybody to be logged on to the server.

Page 66 first paragraph of MCTS Guide to Microsoft Windows Server 2008 Active Directory Configuration

Wintel is a software product. The purpose and function of Wintel is to allow host operating systems to run in a protected format.

DHCPACK

I don't believe so. Trust relationships are between sites, domains, or forests, not client workstations.

schema master and domain naming master

Only one Schema Master are user in Forest

Use the command dnscmd.exe

Server 2008 doesn't automatically shut down; that would be counterproductive in a production environment. I would need more information as to why your server appears to be doing this.

The only reason I can think of for a shutdown is if the server were not activated or was past the evaluation date on an evaluation copy of the server.

ISTG is responsible for this process

Preparing Active Directory (One-Time)

Based on what I've seen so far, it appears as if a partial RFC 2307-compliant schema is included by default with Windows Server 2003 R2. This means that it is no longer necessary to extend the schema to include attributes such as uid, gid, login shell, etc. However, while the schema does appear to be present by default (based on explorations using ADSI Edit), you must install the “Server for NIS” component on at least one domain controller in order to be able to actually set those attributes (and it will be necessary to set those attributes using the Active Directory Users and Computers console before logins from Linux will work).

However, to optimize Active Directory logins from Linux systems, it's also necessary to index the uid attribute in Active Directory. By default, most PAM-enabled systems use the uid attribute as the default login attribute (refer to the “pam_login_attribute” parameter in the /etc/ldap.conf file). Logins will work without having this attribute indexed, but as was discovered in a recent VAS installation, this can introduce delays and drive CPU utilization through the roof. Use the Schema Management MMC snap-in to check the box labeled “Index this attribute in the Active Directory” for the uid attribute. (If you don't want to index the uid attribute, change the value of the pam_login_attribute to something like sAMAccountName, which is already indexed.)

Next, create a new global security group that will act as the default group for Linux-enabled users. Be sure to set the values on the “UNIX Attributes” tab for this group. Add the users that will authenticate to this group using both the “Members” tab and the members list on the “UNIX Attributes” tab.

Finally, you'll also need to create an account in Active Directory that will be used to bind to Active Directory for LDAP queries. This account does not need any special privileges; in fact, making the account a member of Domain Guests and not a member of Domain Users is perfectly fine.

Each of these tasks are one-time tasks that must be accomplished before logins from Linux will work. Once they have been completed, you are ready to configure the individual users.

Preparing Active Directory (Each User)

Each Active Directory account that will authenticate via Linux must be configured with a uid and other UNIX attributes. This is accomplished via the new “UNIX Attributes” tab on the properties dialog box of a user account. Installing the “Server for NIS” component enables this new tab, as mentioned previously.

Each user must be given an NIS domain, but this parameter is ignored in our authentication scheme. Each user must also have a unique uid; I believe that the Server for NIS defaults at a starting uid of 10000, which is pretty safe for most systems. In addition, each member must have a gid (group ID); simply specify the group that was created earlier. Be sure to also specify a login shell (such as “/bin/bash”) and a home directory (such as “/home/slowe”).

After all the user accounts have been configured, then we are ready to perform the additional tasks within Active Directory and on the Linux server that will enable the authentication.

Preparing Active Directory (Each Linux Server)

Here is where it starts getting tricky. So far, nothing we've done has been unusual or terribly difficult. Things will start getting a bit more complex now.

First off, you'll need to decide if you want to use TGT validation. I don't have the space here to fully describe this, but basically it's a check that the Kerberos Key Distribution Center (KDC-in this case, an Active Directory domain controller) is not being spoofed. It's an added level of security that ensures that all hosts involved are indeed who they say they are, which is one of the core principles of the Kerberos authentication system.

Without TGT Validation

If you don't care about TGT validation, then ignore this whole section and proceed to “Preparing Each Linux Server”, below. Once Linux is properly configured for Kerberos authentication and LDAP lookups, it can authenticate against Active Directory with no further action required. You'll note that this is in contrast to many of the instructions out there (including my original instructions), which state that you must perform additional steps. In my experience, the additional steps are only necessary if you want TGT validation, i.e., if you want the Linux server to verify the identity of the Active Directory domain controller handing out the Kerberos tickets. If you don't care about that, then you're ready to proceed with the next step.

With TGT Validation

For each Linux-based server that will be authenticating against Active Directory, follow the steps below.

1. Create a computer account in Active Directory. When creating the computer account, be sure to specify that this account may be used by a pre-Windows 2000-based computer.

2. Use the following command at a command prompt to configure the new computer account:

ktpass -princ HOST/fqdn@REALM -mapuser DOMAIN\name$

-crypto DES-CBC-MD5 +DesOnly -pass password -ptype KRB5_NT_SRV_HST

-out filename

Of course, you'll need to substitute the appropriate values for “fqdn” (the fully-qualified domain name of the computer), “REALM” (the DNS name of your Active Directory domain in UPPERCASE), “DOMAIN” (the NetBIOS name of your Active Directory domain), “name$” (the name of the computer account created, with a dollar sign appended at the end), “password” (the password that will be set for the new computer account), and “filename” (the keytab that will be generated and must be copied over to the Linux computer). Please note (and this is important) that the “HOST/fqdn@REALM” portion is case-sensitive and should be typed as shown above.#160; Of course, if you are repeating this process for multiple servers, please be sure to use a unique filename for each keytab generated using ktpass.exe. (I use each Linux server's hostname as the filename.)

If this computer account ever gets deleted from Active Directory, then Active Directory users will be unable to authenticate to Linux systems. You'll need to repeat the process-create a new computer account, run ktpass.exe, and copy the keytab over to the Linux server (as described below).

Preparing Each Linux Server

Follow the steps below to configure each Linux server for authentication against Active Directory.

1. Make sure that the appropriate Kerberos libraries, OpenLDAP, pam_krb5, and nss_ldap are installed. If they are not installed, install them.

2. Be sure that time is being properly synchronized between Active Directory and the Linux server in question. Kerberos requires time synchronization. Set up NTP if necessary.

3. Edit the krb5.conf file to look something like this, substituting your actual host names and domain names where appropriate:

[logging]

default = FILE:/var/log/krb5libs.log

kdc = FILE:/var/log/krb5kdc.log

admin_server = FILE:/var/log/kadmind.log

[libdefaults]

default_realm = EXAMPLE.COM

dns_lookup_realm = true

dns_lookup_kdc = true

#[realms]

# EXAMPLE.COM = {

# kdc = host.example.com:88

# admin_server = host.example.com:749

# default_domain = example.com

# }

[domain_realm]

.example.com = EXAMPLE.COM

example.com = EXAMPLE.COM

[kdc]

profile = /var/kerberos/krb5kdc/kdc.conf

[appdefaults]

pam = {

debug = false

ticket_lifetime = 36000

renew_lifetime = 36000

forwardable = true

krb4_convert = false

validate = true

}

Note that the line “validate =” should be set to true if you want TGT validation; otherwise, set it to false. Note also that we've commented out the [realms] section because we are using DNS to locate the KDCs (“dns_lookup_kdc = true”); this requires the presence of the appropriate SRV records in DNS. In a correctly-functioning Active Directory environment, these records will be present.

4. Edit the /etc/ldap.conf file to look something like this, substituting the appropriate host names, domain names, account names, and distinguished names (DNs) where appropriate.

host 10.10.10.10

base dc=example,dc=com

uri ldap://server.example.com/

binddn ldap@example.com

bindpw adldapbindpw

scope sub

ssl no

pam_filter objectClass=User

nss_base_passwd dc=example,dc=com?sub

nss_base_shadow dc=example,dc=com?sub

nss_base_group dc=example,dc=com?sub

nss_map_objectclass posixAccount user

nss_map_objectclass shadowAccount user

nss_map_objectclass posixGroup group

nss_map_attribute gecos name

nss_map_attribute homeDirectory unixHomeDirectory

nss_map_attribute uniqueMember member

5. Securely copy the file generated by the ktpass.exe command above to the Linux server. You can replace the existing /etc/krb5.keytab file if and only if you do not need any of the existing keys stored there. If you haven't put any keys in there, then you probably don't have any and don't need to worry about using ktutil to merge the new keys (from the file generated by ktpass.exe) with the existing keys. If, however, you do have existing keys you need to maintain, be sure to use ktutil to merge/append the new keys to the existing keytab.

6. Configure PAM (this varies according to Linux distributions) to use pam_krb5 for authentication. Many modern distributions use a stacking mechanism whereby one file can be modified and those changes will applied to all the various PAM-aware services. For example, in Red Hat-based distributions, the system-auth file is referenced by most other PAM-aware services. A sample system-auth file that would be found in /etc/pam.d might look something like this:

#%PAM-1.0

# This file is auto-generated.

# User changes will be destroyed the next time authconfig is run.

auth required /lib/security/$ISA/pam_env.so

auth sufficient /lib/security/$ISA/pam_unix.so likeauth nullok

auth sufficient /lib/security/$ISA/pam_krb5.so

auth required /lib/security/$ISA/pam_deny.so

account sufficient /lib/security/$ISA/pam_krb5.so

account required /lib/security/$ISA/pam_unix.so

account sufficient /lib/security/$ISA/pam_succeed_if.so uid < 100 quiet

account required /lib/security/$ISA/pam_deny.so

password requisite /lib/security/$ISA/pam_cracklib.so retry=3

password sufficient /lib/security/$ISA/pam_unix.so nullok \use_authtok md5 shadow

password required /lib/security/$ISA/pam_deny.so

session required /lib/security/$ISA/pam_limits.so

session required /lib/security/$ISA/pam_unix.so

(Lines have been wrapped above for readability, but should be typed all on a single line.) Of course, each distribution's PAM configuration may be different, so be sure to consult the documentation for your particular distribution. The sample above was taken from CentOS 4.3, with a few modifications. Remember that in Red Hat-based distributions, such as CentOS, running the authconfig program will overwrite all the changes to /etc/pam.d/system-auth, so be careful.

7. Edit the /etc/nsswitch.conf file to include “ldap” as a lookup source for passwd, shadow, and groups.

That should be it. Once you do that, you should be able to use kinit from a Linux shell prompt (for example, “kinit aduser”) and generate a valid Kerberos ticket for the specified Active Directory account.

At this point, any PAM-aware service that is configured to use the stacked system file (such as the system-auth configuration on Red Hat-based distributions) will use Active Directory for authentication. The SSH daemon is a good one to test. Note, however, that unless you also add the pam_mkhomedir.so module in the PAM configuration, home directories will have to be created manually (with the correct permissions and ownership set manually as well) for any Active Directory account that may log on to that server. (I generally recommend the use of pam_mkhomedir.so in this situation.)

Caveats/Limitations/Disclaimers

I haven't tested this configuration on every possible distribution of Linux. This configuration was tested on CentOS 4.3 running as a virtual machine under ESX Server 3.0, authenticating against a pair of domain controllers running Windows Server 2003 R2 (which were also VMs). It should work without major modifications on most other Linux distributions, and with modifications on various other Unix operating systems. (I plan to test OpenBSD 3.9 and possibly Solaris 10 x86 soon.)

Also, even though the “validate = true” setting in /etc/krb5.conf implies that the Kerberos TGT must be validated, pam_krb5 appears to bypass the TGT validation if the keytab is not present or not readable. This means that logins will succeed, even if the keytab is not present or not readable. If the computer account in Active Directory is missing, however, logins will fai

The Routing and Remote Access Services for Windows 2008 is always accepted with a VPN or RRAS. That is all Windows 2008 can handle, along with R2 and an LAN network.

There are many of these - you will have to check through an Internet Search Engine to find one that meets your needs.

There is no Admin pack in windows 2008.

SRV Resource Records

When a Windows 2000-based domain controller starts up, the Net Logon service uses dynamic updates to register SRV resource records in the DNS database, as described in "A DNS RR for specifying the location of services (DNS SRV)

The SRV record is used to map the name of a service (in this case, the LDAP service) to the DNS computer name of a server that offers that service. In a Windows 2000 network, an LDAP resource record locates a domain controller.

A workstation that is logging on to a Windows 2000 domain queries DNS for SRV records in the general form:

_Service ._ Protocol . DnsDomainName

Active Directory servers offer the LDAP service over the TCP protocol; therefore, clients find an LDAP server by querying DNS for a record of the form:

_ldap._tcp. DnsDomainName

_msdcs Subdomain

There are possible implementations of LDAP servers other than Windows 2000-based domain controllers. There are also possible implementations of LDAP directory services that employ Global Catalog servers but are not servers that are running Windows 2000. To facilitate locating Windows 2000-based domain controllers, in addition to the standard _ Service ._ Protocol . DnsDomainName format, the Net Logon service registers SRV records that identify the well-known server-type pseudonyms "dc" (domain controller), "gc" (Global Catalog), "pdc" (primary domain controller, and "domains" (globally unique identifier, or GUID) as prefixes in the _msdcs subdomain. This Microsoft-specific subdomain allows location of domain controllers that have Windows 2000-specific roles in the domain or forest, as well as the location by GUID when a domain has been renamed. To accommodate locating domain controllers by server type or by GUID (abbreviated "dctype"), Windows 2000-based domain controllers register SRV records in the following form:

_ Service ._ Protocol . DcType ._msdcs. DnsDomainName

The addition of the _msdcs subdomain means that two sets of DNS names can be used to find an LDAP server: DnsDomainName is used to find an LDAP server or Kerberos server that is running TCP (or, in the case of a Kerberos server, either TCP or the User Datagram Protocol [UDP]), and the subdomain _msdcs. DnsDomainName is used to find an LDAP server that is running TCP and also functioning in a particular Windows 2000 role. The name "_msdcs" is reserved for locating domain controllers. The single keyword "_msdcs" was chosen to avoid cluttering the DNS namespace unnecessarily. Other constant, well-known names (pdc, dc, and gc) were kept short to avoid exceeding the maximum length of DnsDomainName.

50Mhz100 Mhz120 Mhz150Mhz

it needs to support SRV records.