Jun 09, 2015 Windows Server 2012 Active Directory Kurulumu - Duration: 28:16. Ekrem Aras 15,342 views.
Learning has never been so easy!
This how-to was created on CentOS 6.4 as a client and Windows 2008 Standard R2 as the AD Server. I then followed this how-to on 2 other servers to verify the steps were accurate.
Before you start this process make sure that you either edit your selinux configuration to allow this process or disable it. By default selinux will not allow this authentication method to occur and you will simply get an invalid password response when attempting to log in.
11 Steps totalStep 1: Install the neccessary dependancies
# yum -y install authconfig krb5-workstation pam_krb5 samba-common oddjob-mkhomedir sudo ntp
This will install:
- authconfig which we will use to setup the configuration file basics, there may be parts missing or not quite accurate here, so some of the files seem to need a little massaging to work right later. - krb5-workstation which installs required libraries and binaries to perform authentication against active directory using the kerberos protocol - pam_krb5 this package provides libraries for PAM (Pluggable Authentication Modules) to interface with kerberos - samba-common will installed the required libraries and binaries to join the linux box to the domain so domain accounts are trusted by the local machine - oddjob-mkhomedir this package is used to automatically create home directories when your AD users log into the server the first time - sudo will be used to configure which AD users have permission to perform elevated operations on the linux computer. Step 2: Run authconfig to setup the initial authentication configuration
# authconfig --disablecache --enablewinbind --enablewinbindauth --smbsecurity=ads --smbworkgroup={AD DOMAIN NAME(short version all caps)} --smbrealm={AD DOMAIN NAME(long version all caps)} --enablewinbindusedefaultdomain --winbindtemplatehomedir=/home/{AD DOMAIN NAME(long version all lower case)}/%U --winbindtemplateshell=/bin/bash --enablekrb5 --krb5realm={AD DOMAIN NAME(long version all caps)} --enablekrb5kdcdns --enablekrb5realmdns --enablelocauthorize --enablemkhomedir --enablepamaccess --updateall
This will create the initial configuration files to setup samba and kerberos. Next we will update the initial files to make sure they are correct.
Step 3: Verify that your /etc/krb5.conf file looks like this
[logging]
default = FILE:/var/log/krb5libs.log kdc = FILE:/var/log/krb5kdc.log admin_server = FILE:/var/log/kadmind.log
[libdefaults]
default_realm = AD DOMAIN NAME.XXX} dns_lookup_realm = true dns_lookup_kdc = true ticket_lifetime = 24h renew_lifetime = 7d forwardable = true
[realms]
{AD DOMAIN NAME.XXX} = { admin_server = {pdc host name}.{ad domain name.xxx} kdc_server = {pdc host name}.{ad domain name.xxx} }
{ad domain name.xxx} = {
}
[domain_realm]
.{ad domain name.xxx} = {AD DOMAIN NAME.XXX} {ad domain name.xxx} = {AD DOMAIN NAME.XXX}
xxx = your domain extenion. i.e. loc, local, com, ...
pdc = your global catalog servers hostname Step 4: Test that domain authentication via kerberos is working
# kinit {ad username}
You should be returned to a prompt with no output if authentication works correctly. If you receive an error at this point, stop and resolve the error. If you do get an error, it will be something related to the krb5.conf file and the active directory setup. Compare all of your configuration directives and try it again until you can authenticate against AD with this command.
Step 5: Sync the linux servers time with the ad server
# ntpdate {fqdn of ad server}
This will ensure the servers times are in sync as the time is used in hashing passwords during the process of joining the domain.
Step 6: Join the linux box to the AD Domain
# net ads join {AD DOMAIN NAME(long version all lower case)} -U {ad user authorized to join computers to domain}
You can then test that the join succeeded if you have any doubts using
# net ads testjoin
That command will reply with a good indicator if your all good to go.
This step is reliant on /etc/sama/smb.conf configuration file. If you have problems here, that would be a good place to start troubleshooting the issue.
Step 7: Setup a home folder to store active directory user accounts
# mkdir /home/{ad domain name.xxx}
# chmod 777 /home/{ad domain name.xxx}/
Now when your AD users log into this box, a home directory will be created for them automatically in this location.
Step 8: Update your /etc/pam.d/system-auth
This will update the authentication system so that AD users that are members of the linuxusers group will be able to access the system. Other AD users will not.
#%PAM-1.0
# This file is auto-generated. # User changes will be destroyed the next time authconfig is run. auth required pam_env.so auth sufficient pam_unix.so nullok try_first_pass auth requisite pam_succeed_if.so uid >= 500 quiet auth sufficient pam_krb5.so use_first_pass auth required pam_deny.so
account required pam_access.so
account required pam_unix.so broken_shadow account [default=ignore success=1] pam_succeed_if.so uid < 16777216 quiet account [default=bad success=ignore] pam_succeed_if.so user ingroup linuxusers quiet account sufficient pam_localuser.so account sufficient pam_succeed_if.so uid < 500 quiet account [default=bad success=ok user_unknown=ignore] pam_krb5.so account required pam_permit.so
password requisite pam_cracklib.so try_first_pass retry=3 type=
password sufficient pam_unix.so sha512 shadow nullok try_first_pass use_authtok password sufficient pam_krb5.so use_authtok password required pam_deny.so
session optional pam_keyinit.so revoke
session required pam_limits.so session optional pam_oddjob_mkhomedir.so umask=0077 session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session required pam_unix.so session optional pam_krb5.so
Pay close attention to the account directives, this is where you stipulate the order of what accounts are authorized to access services via PAM.
Step 9: Add the linuxusers group to /etc/sudoers
# echo '%linuxusers ALL=(ALL) NOPASSWD:ALL' >> /etc/sudoers
This will allow your users who are part of the active directory group 'linuxusers' to perform elevated tasks on the server via sudo. The NOPASSWD can be replaced with ALL which will cause the server to ask the user again for their password. More secure, but if you're box is secured in other ways (as mine are) I find this to be more annoying than anything else...
On a side note, linux does not like spaces in the group names, so I've found that adding Domain Admins to this area doesn't work well, nor using that in PAM. honetsly though, it doesn't work at all.... So if you want to use a default m$ group, replace the space in the group name with an underscore or get rid of it all together in Active Directory.
Step 10: Make sure required services are set to start on boot
# chkconfig oddjobd on
# chkconfig winbind on # chkconfig messagebus on Step 11: reboot the linux box and you should be ready to start authenticating your active directory users.
# init 6
In all honesty you don't have to reboot, you can simply start/restart the services you just turned on in step 9, but it's nice to know that the next time the power goes out and your server restarts everything will come up just fine... ;-)
![]()
There you go, 11 simple steps to enable active directory authentication on a CentOS6.4 server. Hope this helps others and saves you the time I lost trying to make this work.... Just remember SELINUX!!!! Or you'll bang your head against a wall for 2 days like I did wondering why your password or username is wrong...
Published: Jul 25, 2013 · Last Updated: Dec 10, 2014
51 Comments
Active Directory (AD) is a directory service that Microsoft developed for the Windows domain networks. It is included in most Windows Serveroperating systems as a set of processes and services.[1][2] Initially, Active Directory was only in charge of centralized domain management. Starting with Windows Server 2008, however, Active Directory became an umbrella title for a broad range of directory-based identity-related services.[3]
A server running Active Directory Domain Service (AD DS) is called a domain controller. It authenticates and authorizes all users and computers in a Windows domain type networkâassigning and enforcing security policies for all computers and installing or updating software. For example, when a user logs into a computer that is part of a Windows domain, Active Directory checks the submitted password and determines whether the user is a system administrator or normal user.[4] Also, it allows management and storage of information, provides authentication and authorization mechanisms, and establishes a framework to deploy other related services: Certificate Services, Active Directory Federation Services, Lightweight Directory Services and Rights Management Services.[5]
Active Directory uses Lightweight Directory Access Protocol (LDAP) versions 2 and 3, Microsoft's version of Kerberos, and DNS.
History[edit]
Active Directory, like many information-technology efforts, originated out of a democratization of design using Request for Comments or RFCs. The Internet Engineering Task Force (IETF), which oversees the RFC process, has accepted numerous RFCs initiated by widespread participants. Active Directory incorporates decades of communication technologies into the overarching Active Directory concept then makes improvements upon them.[citation needed] For example, LDAP underpins Active Directory. Also X.500 directories and the Organizational Unit preceded the Active Directory concept that makes use of those methods. The LDAP concept began to emerge even before the founding of Microsoft in April 1975, with RFCs as early as 1971. RFCs contributing to LDAP include RFC 1823 (on the LDAP API, August 1995),[6]RFC 2307, RFC 3062, and RFC 4533.[7][8][9]
Microsoft previewed Active Directory in 1999, released it first with Windows 2000 Server edition, and revised it to extend functionality and improve administration in Windows Server 2003. Additional improvements came with subsequent versions of Windows Server. In Windows Server 2008, additional services were added to Active Directory, such as Active Directory Federation Services.[10] The part of the directory in charge of management of domains, which was previously a core part of the operating system,[10] was renamed Active Directory Domain Services (ADDS) and became a server role like others.[3] 'Active Directory' became the umbrella title of a broader range of directory-based services.[11] According to Bryon Hynes, everything related to identity was brought under Active Directory's banner.[3]
Active Directory Services[edit]
Active Directory Services consist of multiple directory services. The best known is Active Directory Domain Services, commonly abbreviated as AD DS or simply AD.[12]
Domain Services[edit]
Active Directory Domain Services (AD DS) is the cornerstone of every Windows domain network. It stores information about members of the domain, including devices and users, verifies their credentials and defines their access rights. The server running this service is called a domain controller. A domain controller is contacted when a user logs into a device, accesses another device across the network, or runs a line-of-business Metro-style appsideloaded into a device.
Other Active Directory services (excluding LDS, as described below) as well as most of Microsoft server technologies rely on or use Domain Services; examples include Group Policy, Encrypting File System, BitLocker, Domain Name Services, Remote Desktop Services, Exchange Server and SharePoint Server.
Lightweight Directory Services[edit]
Active Directory Lightweight Directory Services (AD LDS), formerly known as Active Directory Application Mode (ADAM),[13] is a light-weight implementation of AD DS.[14] AD LDS runs as a service on Windows Server. AD LDS shares the code base with AD DS and provides the same functionality, including an identical API, but does not require the creation of domains or domain controllers. It provides a Data Store for storage of directory data and a Directory Service with an LDAP Directory Service Interface. Unlike AD DS, however, multiple AD LDS instances can run on the same server.
Certificate Services[edit]
Active Directory Certificate Services (AD CS) establishes an on-premises public key infrastructure. It can create, validate and revoke public key certificates for internal uses of an organization. These certificates can be used to encrypt files (when used with Encrypting File System), emails (per S/MIME standard), and network traffic (when used by virtual private networks, Transport Layer Security protocol or IPSec protocol).
AD CS predates Windows Server 2008, but its name was simply Certificate Services.[15]
AD CS requires an AD DS infrastructure.[16]
Federation Services[edit]
Active Directory Federation Services (AD FS) is a single sign-on service. With an AD FS infrastructure in place, users may use several web-based services (e.g. internet forum, blog, online shopping, webmail) or network resources using only one set of credentials stored at a central location, as opposed to having to be granted a dedicated set of credentials for each service. AD FS's purpose is an extension of that of AD DS: The latter enables users to authenticate with and use the devices that are part of the same network, using one set of credentials. The former enables them to use the same set of credentials in a different network.
As the name suggests, AD FS works based on the concept of federated identity.
AD FS requires an AD DS infrastructure, although its federation partner may not.[17]
Rights Management Services[edit]
Active Directory Rights Management Services (AD RMS, known as Rights Management Services or RMS before Windows Server 2008) is a server software for information rights management shipped with Windows Server. It uses encryption and a form of selective functionality denial for limiting access to documents such as corporate e-mails, Microsoft Word documents, and web pages, and the operations authorized users can perform on them.
Logical structure[edit]
As a directory service, an Active Directory instance consists of a database and corresponding executable code responsible for servicing requests and maintaining the database. The executable part, known as Directory System Agent, is a collection of Windows services and processes that run on Windows 2000 and later.[1] Objects in Active Directory databases can be accessed via LDAP, ADSI (a component object model interface), messaging API and Security Accounts Manager services.[2]
Objects[edit]
A simplified example of a publishing company's internal network. The company has four groups with varying permissions to the three shared folders on the network.
Active Directory structures are arrangements of information about objects. The objects fall into two broad categories: resources (e.g., printers) and security principals (user or computer accounts and groups). Security principals are assigned unique security identifiers (SIDs).
Each object represents a single entityâwhether a user, a computer, a printer, or a groupâand its attributes. Certain objects can contain other objects. An object is uniquely identified by its name and has a set of attributesâthe characteristics and information that the object representsâ defined by a schema, which also determines the kinds of objects that can be stored in Active Directory.
The schema object lets administrators extend or modify the schema when necessary. However, because each schema object is integral to the definition of Active Directory objects, deactivating or changing these objects can fundamentally change or disrupt a deployment. Schema changes automatically propagate throughout the system. Once created, an object can only be deactivatedânot deleted. Changing the schema usually requires planning.[18]
Forests, trees and domains[edit]
The Active Directory framework that holds the objects can be viewed at a number of levels. The forest, tree, and domain are the logical divisions in an Active Directory network.
Within a deployment, objects are grouped into domains. The objects for a single domain are stored in a single database (which can be replicated). Domains are identified by their DNS name structure, the namespace.
A domain is defined as a logical group of network objects (computers, users, devices) that share the same Active Directory database.
A tree is a collection of one or more domains and domain trees in a contiguous namespace, and is linked in a transitive trust hierarchy.
At the top of the structure is the forest. A forest is a collection of trees that share a common global catalog, directory schema, logical structure, and directory configuration. The forest represents the security boundary within which users, computers, groups, and other objects are accessible.
Organizational units[edit]
The objects held within a domain can be grouped into Organizational Units (OUs).[19] OUs can provide hierarchy to a domain, ease its administration, and can resemble the organization's structure in managerial or geographical terms. OUs can contain other OUsâdomains are containers in this sense. Microsoft recommends using OUs rather than domains for structure and to simplify the implementation of policies and administration. The OU is the recommended level at which to apply group policies, which are Active Directory objects formally named Group Policy Objects (GPOs), although policies can also be applied to domains or sites (see below). The OU is the level at which administrative powers are commonly delegated, but delegation can be performed on individual objects or attributes as well.
Organizational units do not each have a separate namespace. As a consequence, for compatibility with Legacy NetBios implementations, user accounts with an identical sAMAccountName are not allowed within the same domain even if the accounts objects are in separate OUs. This is because sAMAccountName, a user object attribute, must be unique within the domain.[20]. However, two users in different OUs can have the same Common Name (CN), the name under which they are stored in the directory itself such as 'fred.staff-ou.domain' and 'fred.student-ou.domain', where 'staff-ou' and 'student-ou' are the OUs.
In general the reason for this lack of allowance for duplicate names through hierarchical directory placement, is that Microsoft primarily relies on the principles of NetBIOS, which is a flat-file method of network object management that for Microsoft software, goes all the way back to Windows NT 3.1 and MS-DOSLAN Manager. Allowing for duplication of object names in the directory, or completely removing the use of NetBIOS names, would prevent backward compatibility with legacy software and equipment. However, disallowing duplicate object names in this way is a violation of the LDAP RFCs on which Active Directory is supposedly based.
As the number of users in a domain increases, conventions such as 'first initial, middle initial, last name' (Western order) or the reverse (Eastern order) fail for common family names like Li (æ), Smith or Garcia. Workarounds include adding a digit to the end of the username. Alternatives include creating a separate ID system of unique employee/student id numbers to use as account names in place of actual user's names, and allowing users to nominate their preferred word sequence within an acceptable use policy.
Because duplicate usernames cannot exist within a domain, account name generation poses a significant challenge for large organizations that cannot be easily subdivided into separate domains, such as students in a public school system or university who must be able to use any computer across the network.
Shadow groups[edit]
In Active Directory, organizational units (OUs) cannot be assigned as owners or trustees. Only groups are selectable, and members of OUs cannot be collectively assigned rights to directory objects.
In Microsoft's Active Directory, OUs do not confer access permissions, and objects placed within OUs are not automatically assigned access privileges based on their containing OU. This is a design limitation specific to Active Directory. Other competing directories such as Novell NDS are able to assign access privileges through object placement within an OU.
Active Directory requires a separate step for an administrator to assign an object in an OU as a member of a group also within that OU. Relying on OU location alone to determine access permissions is unreliable, because the object may not have been assigned to the group object for that OU.
A common workaround for an Active Directory administrator is to write a custom PowerShell or Visual Basic script to automatically create and maintain a user group for each OU in their directory. The scripts are run periodically to update the group to match the OU's account membership, but are unable to instantly update the security groups anytime the directory changes, as occurs in competing directories where security is directly implemented into the directory itself. Such groups are known as Shadow Groups. Once created, these shadow groups are selectable in place of the OU in the administrative tools.
Microsoft refers to shadow groups in the Server 2008 Reference documentation, but does not explain how to create them. There are no built-in server methods or console snap-ins for managing shadow groups.[21]
The division of an organization's information infrastructure into a hierarchy of one or more domains and top-level OUs is a key decision. Common models are by business unit, by geographical location, by IT Service, or by object type and hybrids of these. OUs should be structured primarily to facilitate administrative delegation, and secondarily, to facilitate group policy application. Although OUs form an administrative boundary, the only true security boundary is the forest itself and an administrator of any domain in the forest must be trusted across all domains in the forest.[22]
Partitions[edit]
The Active Directory database is organized in partitions, each holding specific object types and following a specific replication pattern. Microsoft often refers to these partitions as 'naming contexts'.[23] The 'Schema' partition contains the definition of object classes and attributes within the Forest. The 'Configuration' partition contains information on the physical structure and configuration of the forest (such as the site topology). Both replicate to all domains in the Forest. The 'Domain' partition holds all objects created in that domain and replicates only within its domain.,
Physical structure[edit]
Sites are physical (rather than logical) groupings defined by one or more IP subnets.[24] AD also holds the definitions of connections, distinguishing low-speed (e.g., WAN, VPN) from high-speed (e.g., LAN) links. Site definitions are independent of the domain and OU structure and are common across the forest. Sites are used to control network traffic generated by replication and also to refer clients to the nearest domain controllers (DCs). Microsoft Exchange Server 2007 uses the site topology for mail routing. Policies can also be defined at the site level.
Physically, the Active Directory information is held on one or more peer domain controllers, replacing the NTPDC/BDC model. Each DC has a copy of the Active Directory. Servers joined to Active Directory that are not domain controllers are called Member Servers.[25] A subset of objects in the domain partition replicate to domain controllers that are configured as global catalogs. Global catalog (GC) servers provide a global listing of all objects in the Forest.[26][27]Global Catalog servers replicate to themselves all objects from all domains and hence, provide a global listing of objects in the forest. However, to minimize replication traffic and keep the GC's database small, only selected attributes of each object are replicated. This is called the partial attribute set (PAS). The PAS can be modified by modifying the schema and marking attributes for replication to the GC.[28] Earlier versions of Windows used NetBIOS to communicate. Active Directory is fully integrated with DNS and requires TCP/IPâDNS. To be fully functional, the DNS server must support SRV resource records, also known as service records.
Replication[edit]
Active Directory synchronizes changes using multi-master replication.[29] Replication by default is 'pull' rather than 'push', meaning that replicas pull changes from the server where the change was effected.[30] The Knowledge Consistency Checker (KCC) creates a replication topology of site links using the defined sites to manage traffic. Intrasite replication is frequent and automatic as a result of change notification, which triggers peers to begin a pull replication cycle. Intersite replication intervals are typically less frequent and do not use change notification by default, although this is configurable and can be made identical to intrasite replication.
Each link can have a 'cost' (e.g., DS3, T1, ISDN etc.) and the KCC alters the site link topology accordingly. Replication may occur transitively through several site links on same-protocol site link bridges, if the cost is low, although KCC automatically costs a direct site-to-site link lower than transitive connections. Site-to-site replication can be configured to occur between a bridgehead server in each site, which then replicates the changes to other DCs within the site. Replication for Active Directory zones is automatically configured when DNS is activated in the domain based by site.
Replication of Active Directory uses Remote Procedure Calls (RPC) over IP (RPC/IP). Between Sites SMTP can be used for replication, but only for changes in the Schema, Configuration, or Partial Attribute Set (Global Catalog) GCs. SMTP cannot be used for replicating the default Domain partition.[31]
Implementation[edit]
In general, a network utilizing Active Directory has more than one licensed Windows server computer. Backup and restore of Active Directory is possible for a network with a single domain controller,[32] but Microsoft recommends more than one domain controller to provide automatic failover protection of the directory.[33] Domain controllers are also ideally single-purpose for directory operations only, and should not run any other software or role.[34]
Certain Microsoft products such as SQL Server[35][36] and Exchange[37] can interfere with the operation of a domain controller, necessitating isolation of these products on additional Windows servers. Combining them can make configuration or troubleshooting of either the domain controller or the other installed software more difficult.[38] A business intending to implement Active Directory is therefore recommended to purchase a number of Windows server licenses, to provide for at least two separate domain controllers, and optionally, additional domain controllers for performance or redundancy, a separate file server, a separate Exchange server, a separate SQL Server,[39] and so forth to support the various server roles.
Physical hardware costs for the many separate servers can be reduced through the use of virtualization, although for proper failover protection, Microsoft recommends not running multiple virtualized domain controllers on the same physical hardware.[40]
Database[edit]
The Active-Directory database, the directory store, in Windows 2000 Server uses the JET Blue-based Extensible Storage Engine (ESE98) and is limited to 16 terabytes and 2 billion objects (but only 1 billion security principals) in each domain controller's database. Microsoft has created NTDS databases with more than 2 billion objects.[41] (NT4's Security Account Manager could support no more than 40,000 objects). Called NTDS.DIT, it has two main tables: the data table and the link table. Windows Server 2003 added a third main table for security descriptor single instancing.[41]
Programs may access the features of Active Directory[42] via the COM interfaces provided by Active Directory Service Interfaces.[43]
Trusting[edit]
To allow users in one domain to access resources in another, Active Directory uses trusts.[44]
Trusts inside a forest are automatically created when domains are created. The forest sets the default boundaries of trust, and implicit, transitive trust is automatic for all domains within a forest.
Terminology[edit]
Management solutions[edit]
Microsoft Active Directory management tools include:
These management tools may not provide enough functionality for efficient workflow in large environments. Some third-party solutions extend the administration and management capabilities. They provide essential features for a more convenient administration processes, such as automation, reports, integration with other services, etc.
Unix integration[edit]
Varying levels of interoperability with Active Directory can be achieved on most Unix-like operating systems (including Unix, Linux, Mac OS X or Java and Unix-based programs) through standards-compliant LDAP clients, but these systems usually do not interpret many attributes associated with Windows components, such as Group Policy and support for one-way trusts.
Third parties offer Active Directory integration for Unix-like platforms, including:
The schema additions shipped with Windows Server 2003 R2 include attributes that map closely enough to RFC 2307 to be generally usable. The reference implementation of RFC 2307, nss_ldap and pam_ldap provided by PADL.com, support these attributes directly. The default schema for group membership complies with RFC 2307bis (proposed).[51] Windows Server 2003 R2 includes a Microsoft Management Console snap-in that creates and edits the attributes.
An alternative option is to use another directory service as non-Windows clients authenticate to this while Windows Clients authenticate to AD. Non-Windows clients include 389 Directory Server (formerly Fedora Directory Server, FDS), ViewDS Identity Solutions - ViewDS v7.2 XML Enabled Directory and Sun Microsystems Sun Java System Directory Server. The latter two both being able to perform two-way synchronization with AD and thus provide a 'deflected' integration.
Another option is to use OpenLDAP with its translucent overlay, which can extend entries in any remote LDAP server with additional attributes stored in a local database. Clients pointed at the local database see entries containing both the remote and local attributes, while the remote database remains completely untouched.[citation needed]
Administration (querying, modifying, and monitoring) of Active Directory can be achieved via many scripting languages, including PowerShell, VBScript, JScript/JavaScript, Perl, Python, and Ruby.[52][53][54][55] Free and non-free AD administration tools can help to simplify and possibly automate AD management tasks.
Since October 2017 Amazon AWS offers integration with Microsoft Active Directory.[56]
See also[edit]
References[edit]
External links[edit]
Retrieved from 'https://en.wikipedia.org/w/index.php?title=Active_Directory&oldid=901820900'
Comments are closed.
|
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |