Enabling logging for Likewise agents in ESXi

In order to join ESXi hosts to the domain Likewise agents are used to join to the Active Directory domain and for user authentication requests. In order to troubleshoot Active Directory integration you will need to enable logging of the agent as by default they do not generate a log file.

This can be performed by enabling logging for the netlogond, lwoid and lsassd daemons.

1) Modify the file ‘/etc/init.d/netlogond’ file to change the line ‘PROG_ARGS=”–start-as-daemon –syslog‘ to one of the below, if you are using a scratch partition use the second option:

PROG_ARGS="--start-as-daemon --logfile /var/log/netlogond.log --loglevel debug" 

PROG_ARGS="--start-as-daemon --logfile /scratch/log/netlogond.log --loglevel debug"

2) Modify the file ‘/etc/init.d/lwoid‘ file to change the line ‘PROG_ARGS=”–start-as-daemon –syslog to one of the below, if you are using a scratch partition use the second option:

PROG_ARGS="--start-as-daemon --logfile /var/log/lwiod.log --loglevel trace" 

PROG_ARGS="--start-as-daemon --logfile /scratch/log/lwiod.log --loglevel trace"

3) Modify the file ‘/etc/init.d/lsassd‘ file to change the line ‘PROG_ARGS=”–start-as-daemon –syslog”‘ to one of the below, if you are using a scratch partition use the second option:

PROG_ARGS="--start-as-daemon --logfile /var/log/lsassd.log --loglevel trace"

PROG_ARGS="--start-as-daemon --logfile /scratch/log/lsassd.log --loglevel trace"

4) Restart each of the services to apply the changes:

/etc/init.d/netlogond restart

/etc/init.d/lwiod  restart

/etc/init.d/lsassd restart
Advertisements

Unable to join ESXi host to the domain – Error when handling SMB socket

I was recently joining ESXi (5.5.0, 1892794) hosts to a domain to which the task would  fail with the status ‘Errors in Active Directory operations’.  On further investigation of the Likewise agent log on the impacted ESXi host, the following was being written to the log file:

 

ERROR:[SMBSocketReaderMain() /build/mts/release/bora-1471401/likewise/esxi-esxi/src/linux/lwio/server/rdr/socket.c:660] Error when handling SMB socket

 

This issue is due to  the size of the Kerberos Ticket Granting Service (TGS) being very high. From the network capture for SMB errors in the Likewise agent logs where the ‘Security Blob Length’ and ‘Byte Count’ values are greater than the  Max Buffer Size on the domain controller to which the ESXi host is setting up a SMB session which by default is 16644 bytes or 4356 bytes if total memory is less than or equal to 512 MB on the host.

Below is an example of the above values in an SMB network capture:


Security Blob Length: 19314
Byte Count (BCC): 19371

 

In order to resolve this issue, I was required to add a DWORD value name ‘SizeReqBuf’ to the registry key ‘HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters’ where the the value data (Decimal) is greater than the values being returned from the network capture and then restart the domain controller(s).

 

 

Enable strict replication consistency on domain controllers within Active Directory domain

I recently enabled strict replication consistency on my domain controllers in order to follow best practices, where this is not enabled there can be a risk that lingering objects could be replicated to a domain controller. This can occur  when a domain controller in your Active Directory environment is disconnected from the replication topology for an extended period of time, this can cause problems when these lingering objects on the source domain controller are updated and these updates are sent by replication to the destination domain controllers.

You can identity existing lingering objects on your domain controllers by filtering for Event ID 1388 or Event ID 1988 in the domain controller logs, to which can be described as the below:

  • Event ID 1388: Inbound replication of the lingering object has occurred on the destination domain controller. 
  • Event ID 1988: Inbound replication of the directory partition of the lingering object has been blocked on the destination domain controller. 

If you have any lingering objects identified, you will need to remove this prior to enabling strict replication consistency, by performing the below:

1) Identity the DSA object GUID of the domain controller reporting lingering objects or partitions.

repadmin /showrepl %ServerName%

2)  Review the lingering objects reported on the domain controller for the directory parition reported in the event log, the adivsory_mode switch will log the lingering objects but not remove them. 

repadmin /removelingeringobjects %ServerName% %ServerGUID% %DirectoryPartition% /advisory_mode

3) Once reviewed, remove the lingering objects.

repadmin /removelingeringobjects %ServerName% %ServerGUID% %DirectoryPartition%

So once the lingering objects have been removed we  can enable stict replication consistency on each domain controller or for all domain controllers in the forest (*).

repadmin /regkey <DC_LIST> +strict

This will modify the registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters. to set the value for Strict Replication Consistency to 0 (enable). You can disable strict replication consistency by running the command but with the disable switch

repadmin /regkey <DC_LIST> -strict

Enable protection from accidental deletion on all organizational units in Active Directory domain

As part of running the best practice analyser for Active Directory, I wanted to protect all organizational units from accidental deletion, this is achievable by using both the Get-ADOrganizationalUnit and Set-ADOrganizationalUnit cmdlets.

First of all I wanted to see which organizational units were not protected from accidental deletion, we can do this by invoking the Get-ADOrganizationalUnit against the domain to filter all organizational units where the ProtectedFromAccidentalDeletion value is set to ‘false’.

Get-ADOrganizationalUnit -filter * -Properties ProtectedFromAccidentalDeletion | where {$_.ProtectedFromAccidentalDeletion -eq $false} | Select-Object DistinguishedName

Now, I wanted to edit the value to be true and enable accidental protection on those organizational units returned, therefore using the original command and piping the output to the Set-ADOrganizationalUnit cmdlet to set the value to ‘true’.

Get-ADOrganizationalUnit -filter * -Properties ProtectedFromAccidentalDeletion | where {$_.ProtectedFromAccidentalDeletion -eq $false} | Set-ADOrganizationalUnit -ProtectedFromAccidentalDeletion $true

By invoking  the initial command I can now verify that all organizational units are now protected agaisnt accidental deletion as no results are returned.

However, I would have one issue with the above is that I required one organizational unit not to be protected against accidental deletion due to an automated process which created and removed child organizational units from a particular search base in the domain. Therefore, I used the cmdlets above to return all organizational units that have the ProtectedFromAccidentalDeletion value set to true by filtering the query to a particular organizational unit and recursively setting the value on each child organizational unit.

Get-ADOrganizationalUnit -filter * -SearchBase "OU=Application,OU=ServiceAccounts,DC=domain,DC=local" -Properties ProtectedFromAccidentalDeletion | where {$_.ProtectedFromAccidentalDeletion -eq $true} | Set-ADOrganizationalUnit -ProtectedFromAccidentalDeletion $false

It is possible to set the ProtectedFromAccidentalDeletion value as true as the default behavior when creating new organisational units, as per this article.

I have not performed this step yet as I would like to do some further testing and also modify the automated workflow as described above that for any organizational units that are created as part of my process, the ProtectedFromAccidentalDeletion value is set to ‘false’.

Enabling Active Directory authentication for Puppet Console Authentication

As part of my Puppet Master server installation I wanted to enable Active Directory authentication based on the membership of security group to restrict access to the console rather than using the default local console authentication mechanism.

Firstly, you are required to disable the console authentication by running the following with elevated root privelages:

sudo /opt/puppet/bin/rake -f /opt/puppet/share/console-auth/Rakefile console:auth:disable

Once the console authentication mechanism has been disabled you will be required to edit the following file to use Active Directory authentication by running the following with elevated root privelages:

sudo vi /etc/puppetlabs/httpd/auth.d/puppetconsole_auth.ad 

In the below example I will use the following configuration settings in order to build the configuration file:

Username: SVCreadad
Password: P@55word!
Domain Controller: DC1
LDAP Search Parameter: OU=Users,DC=dean,DC=local
Security Group: PuppetConsole-Allow

<Location />
AuthType Basic
AuthBasicProvider ldap
AuthName “Puppet Enterprise Console”

# Binding credentials, most AD doesn’t allow anon binding.
AuthLDAPBindDN “CN=SVCreadad,OU=Users,DC=dean,DC=local”
AuthLAPBindPassword “P@55word!”

#User Specification
AuthLDAPURL “ldap://dc1.dean.local/OU=Users,DC=dean,DC=local?SAMAccountName?sub?(objectClass=*)

# Requires that the user is a member of the specified security groups
AuthLDAPGroupAttributeIsDN on
require ldap-group CN=PuppetConsole-Allow,DC=dean,DC=local

</Location >

Save the updated file and run the following command with elevated root privelages:

sudo vi /etc/puppetlabs/httpd/conf.d/puppetdashboard.conf

Uncomment the below line which references the file we have just modified and save the configuration file

# Include /etc/puppetlabs/httpd/auth.d/puppetconsole_auth.ad 

Restart the pe-httd service by running the following command with elevated root privelages

sudo /etc/init.d/pe-httpd restart

Enabling Active Directory Recycle Bin on Windows 2008 R2

Well I have been a bit lazy recently in terms of my certification and in particular refreshing my MCSA (2003). So, I have decided to make a start, which will ultimately be disrupted by my summer holidays (or should I say honeymoon!). First up I am going to prepare for the 70-640: Windows Server 2008 Active Directory: Configuring.

I personally find hands on experience and discussing/blogging about a subject allows it to stay fresh in my mind, whereas reading the training kit or various other materials page by page can become a little tedious (even though it can be required and the materials are generally well written by their respective authors).

So firstly, I wanted to get to grips with the Active Directory Recycle Bin feature which was introduced in Windows Server 2008 R2.

So the virtual lab has been created, so lets make a start…

Forest Functional Level

This is required to be ‘Windows Server 2008 R2’ which is not an issue as I will be installing a new domain in a new forest (where the forest root domain is ‘dean.local’) and will select this to be the functional level on install (default is set to ‘Windows Server 2003).

So what if I had to raise the forest functional level? This can be completed using various steps, I will concentrate on using Active Directory Domains and Trusts snap-in or Active Directory Module for Windows Powershell;

Active Directory Domains and Trusts


1) Start > Administrative Tools > Active Directory Domains and Trusts

2) Highlight and right-click  ‘Active Directory Domains and Trusts’ and select ‘Raise Forest Functional Level’

3) Select ‘Windows Server 2008 R2’ from the drop down menu and select OK.

Active Directory Module for Windows Powershell

1) Start > Administrative Tools > Active Directory Module for Windows Powershell

2) From the command prompt; the cmdlet Set-ADForestMode would be used with the following parameters:

Set-ADForestMode [-Identity] <ADForest> [-ForestMode] <ADForestMode>

For my example, the below command would be used:

Set-ADForestMode -Identity dean.local -ForestMode WindowsServer2008R2Forest

So now we have a supported forest function level how do we enable Active Directory Recycle Bin?

Enabling the Active Directory Recycle Bin

This can be done using either Ldp.exe or the Enable-ADOptionalFeature cmdlet, I will use the cmdlet option as this is the recommended method to be used by Microsoft.

1) Start > Administrative Tools > Active Directory Module for Windows Powershell

2) From the command prompt the cmdlet Enable-ADOptionalFeature would be used with the following parameters:

Enable-ADOptionalFeature -Identity <ADOptionalFeature> -Scope <ADOptionalFeatureScope> -Target <ADEntity>

For my example, the below command would be used:

Enable-ADOptionalFeature –Identity ‘CN=Recycle Bin Feature,CN=Optional Features,CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=dean,DC=local’ –Scope ForestOrConfigurationSet –Target ‘dean.local’

As we see from the above the ADOptionalFeature for the Recycle Bin we are enabling is named:

“CN=Recycle Bin Feature,CN=Optional Features,CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=dean,DC=local’

As enabling the Recycle Bin is an irreversible action, you will be prompted to confirm if you want to perform this action.

So how do I know that this feature has been enabled? Well a quick check of the Directory Service log and I have noticed that two EventIDs have been generated 2136 and 2119 as below:

EventID 2136

Internal Event: An optional feature has been enabled

Optional feature name: Recycle Bin Feature
Optional feature guid: 766ddcd8-acd0-445e-f3b9-a7f9b6744f2a
Scope of optional feature: CN=Partition,CN=Configuration,DC=dean,DC=local

EventID 2119

This Active Directory Domain Services server now supports the Recycle Bin optional feature. When all servers support the optional feature, objects may be undeleted without loss of data.

So now that I have enabled Active Directory Recycle Bin, I shall go away and gets some hands-on experience, remember object may be undeleted without the loss of data!

The next post will confirm that…

Set Extension Attribute value for bulk users in Active Directory

I was recently reminded of a powershell script I compiled many months ago, to set a specified extension attribute to the location of JPEG a on a network share which would be used as the users profile picture within Sharepoint.

The script was dependant on two items. Firstly,  the cmdlet’s require ActiveRoles Management Shell for Active Directory to be installed and the filename of the JPEG file is required to match the username of each user.

As mentioned previously, the script is dependant on the installation of ActiveRoles Management Shell for Active Directory being installed and therefore, we need to load the snap-in to the current session

# Adds the Quest.ActiveRoles.ADManagement snap-in to the current session.
Add-PSSnapin Quest.ActiveRoles.ADManagement

The script will require a number of variables to be specified for the UNC path of the shared folder where the JPEG files are located ($UNC) and  the canonical name of the object in the domain to retrieve user objects ($SearchRoot). In the below examples the UNC path is \\Server\Share\ and the domain object is the ‘Users’ organisational unit located in the domain ‘domain.local.

# Variables required to be completed for UNC path of shared folder and canonical name of domain object
$UNC = “\\Server\Share\”
$SearchRoot = “OU=Users,DC=domain,DC=local”

The script will then invoke the command to retrieve all users in the top level organisational unit and set this as a variable.

# Retrieve all users in the organisational unit and stores them in a variable
$Users = Get-QADUser -SearchRoot $SearchRoot

For each item returned in the loop, the script firstly determines if the JPEG file exists on the network shared folder and then if this does, sets the extensionattribute2 to be the UNC path.

# Provides a loop on each item stored in the variable.
foreach ($User in $Users)
{
# Determines if the profile picture exists for the user.
If (Test-Path ($UNC + $User.SamAccountName +”.jpg”))
{
# If the profile pictures exists, the extensionattribute2 value is changed for the user account.
Set-QADUser -Identity $User.Name -ObjectAttributes @{“extensionattribute2″=”” + $UNC + $User.SamAccountName + “.jpg”}
}
}

The above methodology can be applied for modifying any attribute value within Active Directory, not just my example. Also, the above was compiled in a Windows 2003 domain where the ‘Active Directory Module for Windows PowerShell’ was not available so by using the cmdlets loaded by this snap-in, the dependency on ActiveRoles Management Shell for Active Directory can be removed.