0
Active Directory
Active Directory is a set of networking services made by Microsoft. Questions about using and configuring Active Directory belong here.
849 Questions
What does it mean when the Global Catalog checkbox is selectead?
This checkbox makes the directory structure within a computer network forest transparent to users who perform a search on the network. This information is auto catalogued in the Global Catalog.
What operation requires the active directory domain service to be taken offline?
offline defragmentation
How do you view all the GCs in the forest?
C:\>repadmin /showreps
domain_controller
OR
You can use Replmon.exe for the same purpose.
OR
AD Sites and Services and nslookup gc._msdcs.
To find the in GC from the command line you can try using DSQUERY command.
dsquery server -isgc to find all the gc's in the forest
you can try dsquery server -forest -isgc.
The physical component of Active directory contain all the physical subnet present in your network like domain controllers and replication between domain controllers.
The logical structure of active directory include forest, domains, tree, OUs and global catalogs.
Domain : a group of computer and other resources that are part of a windows server2003 network and share a common directory database.
Global catalog : Global catalog used to catch information about all object in a forest , the global catalog enables users and applications to find object in an active directory domain tree if the user or application knows one or more attributes of the target object.
Tree : Tree as is collection of Active directory Domain, that means the trust relationship can be used by all other domain in the forest as a means to access the domain.
Organization Unit - Organization Unit is a Active directory container into which object can be grouped for per mission management.
Forest : Active directory forest as due to represents the external boundary of the directory service.
These are two types of active directory forest :-
I) Single Forest
2) Multiple forest
What are directory partitions?
Configuration Contains the Configuration container, which stores configuration objects for the entire forest in cn=configuration,dc= forestRootDomain . Updates to this container are replicated to all domain controllers in the forest. Configuration objects store information about sites, services, and directory partitions. You can view the contents of the Configuration container by using ADSI Edit.
Schema Contains the Schema container, which stores class and attribute definitions for all existing and possible Active Directory objects in cn=schema,cn=configuration,dc= forestRootDomain . Updates to this container are replicated to all domain controllers in the forest. You can view the contents of the Schema container in the Active Directory Schema console.
Domain Contains a < domain > container (for example, the abc.com container), which stores users, computers, groups, and other objects for a specific Windows 2000 domain (for example, the abc.com domain). Updates to the < domain> container are replicated to only domain controllers within the domain and to Global Catalog servers if the update is made to an attribute that is marked for replication to the Global Catalog. The < domain > container is displayed in the Active Directory Users and Computers console. The hierarchy of domain directory partitions can be viewed in the Active Directory Domains and Trusts console, where trust relationships between domains can be managed.
Each directory partition is a contiguous portion of the directory tree, and each one starts at a single point (the directory partition head ) and spreads to either leaf nodes (for the schema and configuration directory partitions) or to the heads of other directory partitions below it (for domain directory partitions). Each directory partition, therefore, has exactly one directory partition immediately above it in the tree (except for a tree root domain directory partition, which has only the rootDSE above it) and possibly more directory partitions immediately below it
What is the working principle of DNS server?
To resolve host names to IP address eg wiki.answers.com to 192.41.64.63 or YourComputerName to 192.168.1.XX
If it wasnt for this to access a website you would need to type the IP address of the site or to access a share on a computer in stead of typing \\computername you would need to type the computer IP
DNS also does the opposite IP to Hostname so you can do a lookup on an IP address and find out the hostname
for example if you go in to command promt and do tracert yourcompIP it will say tracing route of YourCOmputer Name [YourCOmputerIP]
What is trust in Windows Server 2003?
trust is used for different domains we can log-in to different users this known as
trust
trust divided 3 types
1 one way incoming
2 one way outgoing
3 two way trust
When the computer is a domain client then secure log on is required?
Yes, if the client is part of the domain then the standard procedure is to log into the domain, which requires a secure login.
However, the client could also log on locally to the machine, not the domain, in which case the log on requirements are not as strict.
Where are locations of the anywho reverse directory?
The anywho reverse directory can be found on the Anywho website. It can be used in any residential area, so there are no exact limitations on the specific location of said service.
What are two group types and three group scopes?
â– Security groups Security groups are used to group domain users into a single administrative unit. Security groups can be assigned permissions and can also be used as e-mail distribution lists. Users placed into a group inherit the permissions assigned to the group for as long as they remain members of that group. Windows itself uses only security groups.
â– Distribution groups These are used for nonsecurity purposes by applications other than Windows. One of the primary uses is within an e-mail
As with user accounts, there are both local and domain-level groups. Local groups are stored in a local computer's security database and are intended to control resource access on that computer. Domain groups are stored in Active Directory and let you gather users and control resource access in a domain and on domain controllers
Group scopes determine where in the Active Directory forest a group is accessible and what objects can be placed into the group. Windows Server 2003 includes three group scopes: global, domain local, and universal.
â– Global groups are used to gather users that have similar permissions requirements. Global groups have the following characteristics:
1. Global groups can contain user and computer accounts only from the domain in which the global group is created.
2. When the domain functional level is set to Windows 2000 native or Windows Server 2003 (i.e., the domain contains only Windows 2000 or 2003 servers), global groups can also contain other global groups from the local domain.
3. Global groups can be assigned permissions or be added to local groups in any domain in a forest.
â– Domain local groups exist on domain controllers and are used to control access to resources located on domain controllers in the local domain (for member servers and workstations, you use local groups on those systems instead). Domain local groups share the following characteristics:
1. Domain local groups can contain users and global groups from any domain in a forest no matter what functional level is enabled.
2. When the domain functional level is set to Windows 2000 native or Windows Server 2003, domain local groups can also contain other domain local groups and universal groups.
â– Universal groups are normally used to assign permissions to related resources in multiple domains. Universal groups share the following characteristics:
1. Universal groups are available only when the forest functional level is set to Windows 2000 native or Windows Server 2003.
2. Universal groups exist outside the boundaries of any particular domain and are managed by Global Catalog servers.
3. Universal groups are used to assign permissions to related resources in multiple domains.
4. Universal groups can contain users, global groups, and other universal groups from any domain in a forest.
5. You can grant permissions for a universal group to any resource in any domain
Time synchronize which fsmo role will capture?
PDC Emulator will be responsible for time synchronization
follow the follwing steps
gponame->
User Configuration->
Windows Settings->
Remote Installation Services-> Choice Options is your friend
Is the SAM located on the domain controller?
Yes its is located but replaced by another Smaller SAM database
SAM Accounts on a Windows 2000 Server That Becomes a Domain Controller
When you install Active Directory on a computer that is running Windows 2000 Server to create a domain controller, you can either create a new domain or configure the domain controller to contain a copy of an existing domain. In both cases, the existing registry key that contains the SAM database is deleted and is replaced by a new, smaller SAM database. The security principals in this database are used only when the server is started in Directory Services Restore Mode.
The disposition of the security principals in the SAM database on the server is different in each case, as follows:
If you create an additional domain controller in an existing domain, the security accounts in the existing SAM database on the server are deleted. The accounts from the existing domain are replicated to Active Directory on the new domain controller.
If you create a new domain, the security accounts in the existing SAM database are preserved as follows:
User accounts become user objects in Active Directory.
Local groups in the account domain become group objects in Active Directory. The group type indicates a local group.
Built-in local groups become group objects in Active Directory. The group type indicates a built-in local group. These groups retain their constant SIDs and are stored in the Builtin container.
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.
When you restart the computer in directory services restore mode what logon must you use?
Administrator group
What is the purpose of the KCC is to create what?
Why do we need domain controller?
a domain controller (DCO) is a server that responds to security authentication requests (logging in, checking permissions, etc.) within the Windows Server domain
What is the purpose of plasma renin activity?
Plasma renin activity (PRA), also called plasma renin assay, may be used to screen for high blood pressure (hypertension ) of kidney origin, and may help plan treatment of essential hypertension
What is function of Active directory lightweight directory service of server 2008?
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.
