Download the PDF handout

DNS Forwarding
In some companies, they may want to prevent their internal DNS servers accessed by not having them directly accessible on the internet. To do this, a DMZ is created with a DNS server that has access to the internet. The company then uses another DNS server on their internal network. This internal DNS server forwards requests to the DMZ DNS server which forwards DNS requests to the ISP’s DNS server. This means the internal DNS server does not access the internet directly and thus helps protect it. If the DMZ DNS server was to be attacked, the DNS records on the internal DNS would be protected.

Conditional Forwarding
Conditional forwarding is only performed if a condition is met. In this example, DNS requests for the other domain are forwarded to the other company’s DNS server. All other DNS requests are forwarded directly to the ISP’s DNS server.

Download the PDF handout

DNS uses a hierarchy of servers to resolve a single FQDN. Each DNS server resolves part of the domain name until the final DNS server is able to return a record for the FQDN.
Dividing up the DNS name space allows decentralized control, fault tolerance and load balancing.

DNS Name Space
A DNS name is resolved from right to left. The first part of the DNS name is dot. All DNS names end in dot, however you do not need to enter this in as the DNS software will automatically add it to the end of the domain name. There are hundreds of DNS servers that are on the internet that can be used to start the resolving process starting with dot. The function of this DNS server, known as a root hint server, is to provide the address of a DNS server that can resolve the next part of the DNS name.
The next part, top level domain, contains the name next part of the domain name. e.g. .com, .net, .au.
The next level is the second level domain name. These domains name can be registered to a company or individual. Once registered, the administrator has complete control over the domain name. They can create records at this level or additional sub domains under that domain. For example, third and fourth level domain names.

Resolve Example
1) When a DNS name is resolved, the request is first sent to the DNS server configured on the client. This DNS server is responsible for resolving the DNS name. A DNS server that contain source records for a DNS name is called authoritative. In other words, these records are configured directly by the administrator and are not cached. If a DNS server does not have the record required in its cache, it needs to find a DNS server that is an authoritative for that domain name.
2) In order to resolve the DNS name, the DNS server will contact a root hint server. These servers are preconfigured in the DNS server.  The root hint server will provide a DNS server that will be able to resolve the name part of the DNS address. In the example, a .com DNS server.
3) The .com DNS server will be able to provide the client with an address of a DNS server then can resolved the next part of the address, in this case ITFreeTraining.
4) This DNS server holds the records for the ITFreeTraining zone. Thus, when a DNS server communicates with this server, it will be able to obtain DNS records for that zone.

Once the resolve process is complete, the address of each server resolved will remain in the DNS server’s cache so the address of the .com DNS server does not need to be resolved each time. In the real world, the root hint server will often have top level domain names on them as well.

Configuring Root Hints
The DNS server will have the root hint servers configured by default. There will be multiple entries configured in case one or more of the root hint servers is not contactable. Normally there is no need to change them. In some rare cases, a company may choose to disable the root hints servers or use their own. This however is very rare.
In a lot of cases, a company will forward DNS requests to the DNS server run by their ISP. When this occurs, this effectively disables root hints from working since DNS requests are sent direct to the ISP DNS server rather than have the DNS server resolve the request itself.

See http://YouTube.com/ITFreeTraining or http://itfreetraining.com for our always free training videos. This is only one video from the many free courses available on YouTube.

References
“MCTS 70-640 Configuring Windows Server 2008 Active Directory Second edition” pg 440-441
“Domain name” http://en.wikipedia.org/wiki/Domain_name
“Domain Counts & Internet Statistics” http://www.whois.sc/internet-statistics

Previous VideoNext Video

Download the PDF handout

The advantage of using deny domain local group is that it does not require knowledge of what settings have already been configured. The advantage is the administrator can deny a particular right without effecting any other settings on the computer or knowing which setting has already been configured.

Previous VideoNext Video

Download the PDF handout

Fine-Grained Passwords
In order to use fine grained passwords, your domain needs to be Windows Server 2008 Domain Functional Level or higher. This essentially means that all Domain Controllers in your domain need to be Windows Server 2008 or higher and the domain functional level raised to at least Windows Server 2008.  Additional password policies are applied to users or groups not OU’s.

Password Settings Object (PSO)
A Password Settings Object or PSO contains all the same password settings that exist in the Default Domain Policy. In order to change settings and apply them to users and groups, you need to create a new PSO with the same settings as the Default Domain Policy except for the settings you want to change. You cannot choose to change a single setting, all settings must be configured.

When multiple PSO’s are used
Each PSO object has a setting called Password Settings Precedence. This value determines which PSO will be used when multiple PSO objects are being applied. The PSO with the lowest value will be used with the lowest value being 1. If there are multiple PSO’s with the same Password Settings Precedence value than the PSO with the lowest GUID will be used. Every object in Active Directory has a unique GUID which acts like a serial number for the object, thus one PSO will always have a lower GUID.

Demonstration
To change the domain functional level or see what level your domain is currently at, open Active Directory users and Computers, right click the domain and select the option raise domain functional level.

In order to create a new PSO object, you need to run ADSI edit from administrative tools under the start menu. Once open, right click ADSI edit and select the “connect to” option to connect your domain.

Once connected, you need to expand through your domain to “CN=Password Settings Container” located under “CN=System”. To create a new PSO, right click “CN=Password Settings Container” and select new object.

It is a simple matter to complete the questions in the wizard.

Questions that are in the new PSO wizard
Common-Name: This is a friendly name to identify the PSO.
Password Settings Precedence: Must be 1 or greater. When multiple PSO’s are applied to the same user or group, the PSO with the lowest Password Settings Precedence value will be used.
Password reversible encryption status for user account: This indicates whether the password will be stored using a method so the password can be retrieved later on. Values for this are false or true.
Password History Length for user accounts: This indicates how many previous passwords Active Directory should remember and thus prevent the user from using. If the value is 0, no password history will be saved.
Password complexity status for user account: Indicates if a password needs to meet complex password requirements. This means it must have 3 out of 4 of the following. A-Z, a-z, 0-9 or non-alpha numeric. Values are true or false.
Minimum Password Length for user accounts: This value indicates how long the value of the password should be. Valid settings are 0 to 255.
Minimum Password Age for users accounts: This indicates how long the password will need to be used before it can be changed. To disable the settings use the value (none). Otherwise use the setting DD:HH:MM:SS. For example 1 day, 3hours, 5 minutes and 20 seconds would be 1:03:05:20
Maximum Password age for user accounts:  This indicates how long a password can be used before it has to be changed. The value needs to be entered in the format DD:HH:MM:SS. If you do not want the password to ever expire use the value (Never).
Lockout threshold for lockout of user accounts: This indicates the number of wrong password attempts that can be performed before the user account is locked out. Values are 0 through to 65535.
Observation Windows for lockout of user account: This indicates the time period that needs to expire for a reset of the invalid user password count to occur. The value needs to be entered in the format DD:HH:MM:SS. If you do not want the password to ever expire use the value (None).
Lockout duration for lockout user accounts: This value indicates how long a user account will remain locked until it unlocks itself. The value needs to be entered in the format DD:HH:MM:SS. If you do not want the password to ever expire use the value (Never).

Once you create the PSO object you need to associate the object with a user or group. To do this, open the properties for the object and open the attribute msDS-PSOAppliesTo and select the option edit and press the button add Windows Account.

If you want to check which Password Settings a user is obtaining this can be done in Active User in Computer. In order to see the setting, make sure that in Active Directory Users and Computers under the view menu advanced features is ticked. Once advanced options is ticked, open the properties for the user and select the tab attribute editor. To see the attribute, select the filter option and select the option constructed. The attribute msDS-ResultantPSO will tell you which PSO is being applied to that user.

Shadow Group Demonstration
A shadow group is a standard group. The difference is more of a concept than a group type. A shadow group contains all the users under an organizational unit. The members of the group can be kept up to date manually or using a script. There are many different scripts available to perform this. An example of such a script is given below.
“Creating And Managing Shadow Groups” http://dx21.com/ezine/p2p/article.aspx?ID=95
This script needs to be edited to indicate where the group is and where the OU is located.
At the top of the script, look for the following two lines and change them as required.
Const OULDAP = “LDAP://OU=[OUName],DC=[Domain],DC={Ext]”
Const SGLDAP = “LDAP://CN=[GroupName],OU=[OptionalOU],DC=[Domain],DC=[Ext]”

Once the script has been changed, you can run it as required or create a scheduled task to run the script automatically.

References
“MCTS 70-640 Configuring Windows Server 2008 Active Directory Second edition” pg 395-402
“Create a PSO” http://technet.microsoft.com/en-us/library/cc754461(v=ws.10).aspx
“Creating And Managing Shadow Groups” http://dx21.com/ezine/p2p/article.aspx?ID=95

Previous VideoNext Video

Download the PDF handout

Password Policy
Enforce password History: This setting stores the previous passwords used for that user preventing them from using that password again. The default setting is 24.
Maximum password Age: This determines how many days a user can use a password before it expires. When it expires the user will not be able to login or access resources on the network until the password is changed. If you want to prevent the password from expiring for a user, tick the tick box “Password never expires” in the properties for the user.
Minimum password Age: The minimum time a user must have a password before it is changed. This prevents a user changing the password repeatedly until they get to their old password.
Minimum password length: This setting determines the minimum length a password can be.
Password must meet complexity requirements: This means that a password must meet 3 of the following. Contain A-Z, a-z, digits, non- Alphanumeric. Also the password does not contain the username.
Store password using reversible encryption: This stores the password using reversible encryption and thus software is able to work out the password. The password is only reversible once it has been changed. Selecting this option will not grant software access to an existing password.

Account Lockout Policy
When an account is locked, a tick box called unlock account will be ticked in the properties for that user. To unlock the account, clear this tickbox. When the account is locked, the user will not be able to login or make new connections to servers if already logged in.
Account lockout duration: This setting will determine how long a locked account will remain locked before the system will automatically unlock it. If this is set to zero, the administrator must physically unlock the account.
Account lockout threshold: This is the number of failed password attempts until the account is locked. This must occur within the time period contained in the next setting.
Reset account lockout counter after: When the time period set in this setting expires, the timer for account lock out is reset. This means that if the user puts in another wrong password, effectively the counter starts from 0 again.

Kerberos Policy
Unless you have good reason to, these settings should be left on the defaults.
Enforce user logon restrictions: This will check that a user has the required rights before issuing a ticket for access. It is generally quicker to check if the user has the required rights first rather than issue the ticket as the ticket takes a lot of computing power to generate unless you have very slow network connections.
Maximum lifetime for service ticket: Determines how long a service ticket can be used before it has to be recreated.
Maximum lifetime for user ticket: Determines how long a user ticket can be used before it has to be recreated.
Maximum lifetime for user ticket renewal: The time period a ticket can be renewed before it has to be recreated.
Maximum tolerance for computer clock synchronization: How many minutes Kerberos will allow in time difference before the ticket will be rejected.

Cost VS Security
When determining which password settings to use, you should consider the cost that using these settings will have on the organization. Changing user passwords too often will result in more calls to the helpdesk and also users tend to write their passwords down rather than remembering them. Before putting in security settings, perform a cost verses security comparison to determine if the settings should be put in or not.

References
“MCTS 70-640 Configuring Windows Server 2008 Active Directory Second edition” pg 392
“So Long, And No Thanks for the Externalities: The Rational Rejection of Security Advice by Users” https://docs.google.com/viewer?url=http://research.microsoft.com/en-us/um/people/cormac/papers/2009/SoLongAndNoThanks.pdf
“Enforce user logon restrictions” http://msdn.microsoft.com/en-us/library/ms813585.aspx

Previous VideoNext Video

Download the PDF handout

Once the options are enabled, press the add button to add audit entries. At the top of the add Window is the option Select a principal. This option will allow you to select the user or group that you want to audit.

Under the principal option you have the type option. This can be configured to success, failure, or both.

In the middle part of the Windows you can choose which permissions that you want to audit. For example, if you only want to audit when changes are made, you could select the permission write and that is all. You also have the option for show advanced permissions if you want to customize the option further than what is available.

At the bottom of the screen is the option add a condition. This is a new feature in Windows 8 and Windows Server 2012. This option allows you to define and target auditing a lot better than ever before. This helps you capture the information you require rather than capture extra information that you do not require.

Once you have configured which files and folders that you want to audit, auditing needs to be switched on using group policy. To configure the local group policy on a computer, you need to run GPEdit.msc. The auditing settings are found in the following location.
Computer Configuration\Windows Settings\Security Settings\Local Polices\Audit Policy
The setting that need to be configured for file and folder auditing is Audit object access. This can be configured to success, failure, or both.

To View the information generated from File and Folder auditing, this can be done from the Event Viewer under Windows Logs\Security.

Audit object access will record a lot of events in the event logs. These include events for the operating system opening and closing files and objects and also any other auditing settings that you have configured. One point to remember with auditing is that when an object is audited, future audit events may be suppressed. For example, if you audit read and write on a file, Windows will record the first read when the file is opened but will not record additional writes. These are filtered out automatically otherwise the log files would become quite large very fast. If you only want to audit write access, configure the auditing to only audit write access. This way, when a write is performed, the first write access will be recorded in the event viewer. Otherwise, if you are auditing read and write, a read access may be recorded first and write access  will be filtered out and thus not recorded in the event viewer.

References
“MCTS 70-640 Configuring Windows Server 2008 Active Directory Second edition” pg 370-372

Previous VideoNext Video

Download the PDF handout

Demonstration
There are 7 auditing settings in Group Policy found under the following location.
Computer Configuration\Polices\Windows Settings/Local Polices\Audit Policy
To configure a setting, it is just a matter of opening the setting, ticking “Define these policy settings” enabling it and then selecting which settings you want to audit, that is success and failure.

Audit Policy Settings
By default, some auditing settings are configured to audit success events and thus you will have some audit events in the event log even if you do not configure auditing.
Audit account logon events: Audits an event when authentication occurs. For a domain account, this will happen on a Domain Controller. For a local account, this will happen on the computer that the local account is stored on.
Audit Account Management: Auditing when a user performs account management using tools like Active Directory Users and Computers to perform actions like resetting passwords.
Audit Directory Service Audit: Audit any changes to Active Directory Accounts. Includes changes not made with management tools.
Audit Logon Events: This records when a user connects or disconnects from a server. For example, when connecting a map drive to a file server the user needs to logon to the server before the file share can be accessed. This event also records access being denied due to the account being locked. In contrast to Audit Account Logon Event, an event is only recorded when the user is authenticated.
Audit Object Access: This will audit non Active Directory objects, this includes file and folders.
Audit Policy Change: Audits changes to settings like user rights assignment, auditing and trust polices. For example, if you changed a setting and gave a user the” take ownership” right, this setting would record the user rights assignment change in the event log.
Audit Privilege Use: This setting records when privileges are used. An example of a privileges is changing the system time.
Audit Process Tracking: This setting tracks the start and termination of processes in Windows. This setting generates a lot of events so should only be enabled in special circumstances.
Audit System Events: This records events like system start up, shutdown and changes to the system time.

Windows Server 2008 Auditing Change
Before Windows Server 2008, auditing could only track that a value has changed. It would not tell you what the value was before the change. Windows Server 2008 allows the value of an object before the change to be recorded in the event viewer. This means you can effectively know the value was changed and what the value was before the change.

Due to compatibility reasons the option is not enabled by default, in order to enable it run the following command.
auditpol /set /subcategory:”Directory service changes” /success:enable

Demonstration
Before auditing can occur in Windows Server 2008 to record changes to Active Directory objects, the following command needs to run. This only needs to be run once for all Windows Server 2008 installs as it makes a change in Active Directory.
auditpol /set /subcategory:”Directory service changes” /success:enable

When an object is changed, different events are recorded so it is important to find all the events that are related to changes.
For example, when changing an object, this will often log an event for deleting the previous value and then adding a new value. When trying to understand what has been changed, look at a few events around the event that you are interested in case there are multiple events generated for that value change.

References
“MCTS 70-640 Configuring Windows Server 2008 Active Directory Second edition” pg 367-375
“Access Control Lists (Windows)” http://msdn.microsoft.com/en-us/library/windows/desktop/aa374872(v=vs.85).aspx
“AD DS Auditing Step-by-Step Guide” http://technet.microsoft.com/en-us/library/cc731607(WS.10).aspx

Previous VideoNext Video

Download the PDF handout

ACL’s and Auditing
An Access Control List or ACL defines the permissions of an object in Windows. The ACL is divided into two parts. These are the Direct Access Control List (DACL) and System Access Control List (SACL). The DACL is used for permissions like read and write. The SACL is used for auditing permissions like success and failure. Since two systems are used for permissions and auditing, this requires two sets of ACLS. This means that an object can be audited by the auditing system even though there may not be any read permissions defined for that object.

Audit Example
The SACL on an object will determine if this object is audited. However, if the results are recorded in the event viewer, this will be determined by the audit policy. If the audit policy is configured to record events of that audit type, these events will be recorded in the event viewer. Thus, in order for auditing to work, the SACL must be configured to audit events for that object and also the Audit Policy must be configured to allow auditing to occur. By having a system like this, it allows an administrator to quickly change what is audited without having to change the permissions of objects. As auditing puts more load on the system, many administrators will only use auditing when required.

References
“MCTS 70-640 Configuring Windows Server 2008 Active Directory Second edition” pg 367 – 375
“Access Control Lists (Windows)” http://msdn.microsoft.com/en-us/library/windows/desktop/aa374872(v=vs.85).aspx
“AD DS Auditing Step-by-Step Guide” http://technet.microsoft.com/en-us/library/cc731607(WS.10).aspx

Download the PDF handout

Single-Tier Hierarchy
This means that there is one CA on the network. This is suited for small networks. Having one server does mean less administration; however, it does not provide any fault tolerance. In order to issue certificates, the server must be online. The CA contains private keys and when there is only one CA on the network the server cannot be taken offline in order to protect these keys. If an attacker was to obtain these private keys, they could effectively create their own certificates or decrypt any traffic encrypted with any existing certificate.

Two-Tier Hierarchy
This contains two levels of CA’s. One Root CA and any number of child CA’s. In order to improve security, the root CA is usually taken offline after the child CA’s have been issued a certificate. The root CA only ever needs to be brought back online if another child CA is added to the network or a child CA needs to renew its certificate.  Having a second level provides redundancy as multiple CA’s can be created to issue certificates. Different CA’s at the second level can be used for different reasons. For example, one CA may be for internal clients while another CA could be used for external customers or business partners.

Three-Tier Hierarchy
A three tier hierarchy adds another layer of CA’s to the hierarchy. This improves security as the first 2 levels can be taken offline when not required. They can be brought back online only when new CA’s need to be added to the network.

Validity Period
The validity period is how long a certificate is valid for before it cannot be used. The root CA certificate is the top of the hierarchy. Once the root CA certificate expires, all certificates in the hierarchy expire with it. For this reason, the root CA normally has a very high validly period like 20 years. A rule of thumb is that subordinate CA’s have half the value of their parent CA. If they have the same validly period, this would mean that after the CA has been online for a day, it would be issuing certificates that expire after its parent CA.

Download the PDF handout

A certificate is an electronic document that contains data fields. When compared to a traditional paper certificate there are some similarities between an electronic certificate and a physical certificate. Digital certificates like a physical certificate are issued by an authority. For example, a university may issue a certificate to a student to show that they have completed the necessary work in order to graduate. The next question is, would you trust a physically certificate? Digital certificates work the same way. They are issued from an authority and the question becomes would you trust the authority that issued the certificate? Electronic certificates also contain other fields like who or what the certificate was issued to, how long it is valid, the public key and the digital signature. If a digital certificate is presented to a user or computer, the user or computer is able to check the certificate to ensure the person using it should be using it. Also the certificate contains a digital signature which allows the certificate to be checked to make sure it has not been modified.

Digital Signature
A digital signature provides a method for a certificate to be checked to ensure it has not been modified. In order to do this, a hash value is created for the certificate. To generate a hash value the certificate is put through a function to create a single value. Hash functions are designed so different certificates will not produce the same value, however the hash value cannot be used to generate the original certificate.  The same principal applies to a person’s fingerprints. They can be used to identify a person, however using a finger print you could not work out the features of a person like what color hair they have. When a certificate is created, the hash value for that certificate is also created. Using a function involving the private key, a digital signature is created and added to the certificate.

Digital Signature Example
When a certificate is used, in order to check the certificate has not been changed, the following is done: The computer generates the hash value for the certificate. Next, the digital signature is put through a function using the public key which should result in the same hash value. If both values match, the certificate has not been modified. This prevents a 3^rd party taking a certificate, changing the values in the certificate and using the certificate.

Trust Model
Certificates work off a trust model. An example of a trust model in computers is that a computer may have a sticker on it indicating which operating systems it will run. The consumer, seeing this sticker, must trust that the manufacture would not put this sticker on the laptop unless it will run that operating system. The customer must also trust the creator of that operating system would not allow a computer manufacturer to put a sticker on a computer that would not run that operating system.

Certificate Trust Model
Certificates are generally deployed in a hierarchy. At the top is the root certificate authority. This can be an internal Certificate Authority or an external authority like VeriSign. When an authority like VeriSign issues a certificate, they will perform a number of checks on the individual purchasing the certificate to ensure that they are a valid business. When a certificate is used it can be checked to see which authority issued that certificate. In order for the certificate to be used, the computer must trust the authority that it was issued from. Authorities like VeriSign are trusted by default on most operating systems.

Certificate Error
If a certificate is presented to the computer and it is not trusted, the computer will generate an error asking if the users want to trust the certificate. It is up to the user to decide if they believe the certificate is valid.

Certificate Hierarchy
Certificates use a hierarchy. At the top is the root CA, below these are subordinate CA’s. Any level can issue certificates to subordinate CA’s or direct to users, computers or devices. If the user, computer or device trusts the root CA, then any certificate that is issued by any CA in the hierarchy will automatically be trusted and thus used by the client.

References
“MCTS 70-640 Configuring Windows Server 2008 Active Directory Second edition” pg 771-775
“Public key certificate” http://en.wikipedia.org/wiki/Public_key_certificate