Syslog gone mad after vSphere upgrade to vSphere 5.1 update 1


After upgrading a vSphere 5.0 update 2 host to vSphere 5.1 update 1 we noticed an issue with the lsassd daemon. Right after update manager finished with the upgrade the lsassd starts to write a lot of messages. Within the last 5 minutes the syslog server received 170K log messages from the upgraded host alone.

See the screenshot below:

image

The following message keeps popping up in the logs:

esxihost.domain.loc lsassd[9297]: 0x6eb11b90:Terminating on fatal IPC exception

To work around this issue you need to leave the Windows domain. Select the host – Configuration – Authentication Services – Properties. Click on Leave Domain… The excessive logging hast stopped immediately.

image

After that you can rejoin to the Windows domain again.

Advertisement

Domain Controller keeps starting in Directory Service Restore mode


After installing the latest batch of Microsoft updates on one of my virtualized domain controllers. I needed to restart the virtual machine. Nothing interesting so far but when the virtual machine was started I logged on with the correct credentials and noticed that the virtual machine was started in

Check the safeboot parameter via bcdedit:

image

if the safeboot contains DsRepair the domain controller will start in Directory Services repair mode. I don’t know why or who changed the safeboot parameter. But I know how you can delete this value so the VM will start normally. Just run the following command to delete the DsRepair value: bcdedit /deletevalue safeboot and shutdown –r –t 10 to restart the virtual machine.

More information about Directory Services Restore mode can be found here.

ESXi: Leave Windows Domain: The operation is not allow in the current state


Today I was struggling with an ESX host. The ESX host was unable to leave the Windows domain. I got the following error:

image

From the vSphere client I was unable to fix this issue. Apply Host profile failed also with the same error. So I started a search in the VMware KB and found an article about problems while attempting to join a Windows domain. In this article you’ll find a way to clean up the AD configuration from the CLI.

The solution for me was to stop the lsassd service:

/etc/init.d/lsassd stop

Remove the db directory:

/etc/likewise/db directory

and start the lasassd service again:

/etc/init.d/lsassd start

Now I was able to leave the Windows domain.

View Composer: Error during provisioning: Failed to authenticate to AD


Last weekend I was busy with a vCenter migration from vCenter 4.0 on a 32 bit Windows 2003 server to a vCenter 4.1 update 1 server on a Windows 2008 R2 64 bit VM. The database is already running on a separate database server.  The one thing special in this setup was VMware View Composer. So I started the migration and everything went well. vCenter was up and running and VMware View Composer service was started. So it was time to test the provisioning of new Desktops. I changed the pool to deploy 2 new desktops. The process ended with an error:image

I was unable to fix this by myself so I contacted VMware Support and after a while we came up with the following solution: Login to the VMware View Administrator and browse to the vCenter Server page:View Configuration – Servers and select the vCenter server in the the vCenter Servers window and press edit. Now select the Quickprep user for the Desktop pool with the error and press edit:

image

And enter the password for the Quickprep user:

image

After re-entering the password for the Quickprep user, we where ready to test the Desktop pools again. We did a test with an existing Desktop pool and a new pool and both worked as expected. The Desktop pools are working again. I want to thank VMware support for the quick and accurate support.

View Agent is in an unreachable state after deploying a Win XP pool


After the upgrade to VMware View 4.5, I wanted to test a Desktop pool with the new View Agent and Windows XP installed as Guest OS. But when the composer finished his job, it finished with a provisioning error:

image

So after a quick search I found out that this issue is documented on page 286 from view45_admin_guide.pdf:

Windows XP linked-clone desktops can fail to join the domain if your Active Directory runs on Windows Server 2008.

Problem
When linked-clone desktops are provisioned, the linked clones fail to join the domain. View Administrator displays View Composer provisioning error messages. For example:
5/17/10 3:11:50 PM PDT: View Composer agent initialization state error (18): Failed to join the
domain (waited 565 seconds)

Cause
This issue can occur if your Active Directory runs on Windows Server 2008. The Windows Server 2008 readonly domain controller (RODC) is not backward-compatible with Windows XP virtual machines.

Solution
1 Check the View Composer log for the following error message:
0x4f1: The system detected a possible attempt to compromise security. Please ensure that you
can contact the server that authenticated you. By default, the View Composer log file is generated in the Windows Temp directory: C:\Windows\Temp \vmware-viewcomposer-ga-new.log
2 On the parent virtual machine, apply the Windows Server 2008 RODC compatibility update for Windows XP. See Microsoft Support Article 944043 at the following location:
http://support.microsoft.com/kb/944043/en-us.
3 Take a snapshot of the updated parent virtual machine.
4 Recompose the linked-clone desktops from the updated parent virtual machine and snapshot.

You can also find the solution on kb.vmware.com:

This issue occurs when Windows XP desktops fail to join the Windows 2008 Active Directory domain.

To resolve this issue:

  1. Ensure that the Windows XP Master is updated with the latest Microsoft patches.
  2. Ensure that the Windows Server 2008 read-only domain controller (RODC) compatibility pack for Windows Server 2003 and Windows XP clients is installed in the master virtual machine.
    For more information and to download the patch, see the Microsoft Knowledge Base article 944043.
    Note: The preceding link was correct as of January 28, 2011. If you find the link is broken, provide feedback and a VMware employee will update the link.
    After applying the patch, create a new snapshot for use with linked clone pools or convert the virtual machine to a template for full clone or deployment using Sysprep.

After applying the latest Windows XP updates and the patch mentioned above. I was able to deploy the XP desktop pool again. So if you are deploying View desktop with Windows XP in a Windows 2008 domain. Install the patch mentioned in KB944043.

Note. I saw this issue only on desktops with the latest View 4.5 agent installed. The desktop pool with the View 4.0 agent did work as expected.

Sources:

Source Link
VMware http://kb.vmware.com/kb/1027775
VMware http://kb.vmware.com/kb/1030462
VMware http://kb.vmware.com/kb/1027087
Microsoft http://support.microsoft.com/kb/944043/en-us

How To: Configure vSphere 4.1 Active Directory Authentication


In this post I will show you how to setup Active Directory Authentication in vSphere 4.1.

What do we need tot do:

– Before you start. Please make sure that DNS and NTP are fully functional.
– Create an AD group called "ESX Admins" on a Windows Domain Controller
– Add users to that group
– Configure ESX/ESXi server’s "Directory Services"

If your ESX hosts and Active Directory Domain controllers are able to find each other via DNS, you’re ready to go to the next step of this setup. We need to create a group called “ESX Admins” and add the users with administrator permissions in vCenter to this group. When you choose a different name for the group, you will not be able to use Active Directory Authentication. I found this in the vsp_41_esx_server_config.pdf:

vCenter Server registers any selected Windows domain user or group through the process of assigning permissions. By default, all users who are members of the local Windows Administrators group on vCenter Server are granted the same access rights as any user assigned to the Administrator role. Users who are members of the Administrators group can log in as individuals and have full access.
Users who are in the Active Directory group ESX Admins are automatically assigned the Administrator role.

After creating the ESX Admins group it’s now time to join the ESX host to the Windows Domain. When you’re managing a small environment, you can do this with five a six mouse clicks per ESX host.

Continue reading “How To: Configure vSphere 4.1 Active Directory Authentication”

Powershell: Set Logon Hours for all the users in an OU


image

With the script in this post you’re able to set logon hours to a bunch of users. All you have to do is to setup logon hours for a “template” user and define this “template” user into the $template variable.

image

The other step is to define the $ou variable with the path to the OU. In my case this was ict-freak/Gebruikers.

The script will now read the default logon hours and will apply them to the users in the OU.

$template = "" # This is a user with the default logon hours
$ou = "" # the full path to your ou "domainname/ouname1/ouname2"

# Get the logonhours from the template user
$template = Get-QADUser $template -IncludedProperties logonhours
[array]$logonHours = $template.DirectoryEntry.logonHours

# Get all users
$users = Get-QADUser -OrganizationalUnit $ou

# Loop through all the users
foreach($user in $users){
    Set-QADUser $user.Name -oa @{logonHours = $logonHours}
}

 

I found this trick here: http://www.powergui.org/thread.jspa?threadID=7860

Powershell: Add User to a lot of Groups


image 

Update: Dimitry Sotnikov has posted a great article about the new cmdlets. You can read his post here.  After reading Dimitry’s post, I created a new script.

For some test purposes I created a new test user. This test user has to be a member off al my application groups in Active Directory. This job can easily  be done with Powershell and the Quest AD cmdlets.

 
$User = Read-Host ("Username")
Get-QADGroup -Name 'GG_APL_*' -NotContainsIndirectMember $User `
    | Add-QADGroupMember -Member $User

 

To verify the changes, you can run the following script:

$User = Read-Host ("Username")
Get-QADGroup $User | Select Name 

Debian: Samba with AD Authentication


image

This tutorial is a mix-up of other tutorials I found on the net. You’ll find the other sites in the source list at the bottom of this post.

Remember:

Just change ICT-FREAK.LOCAL to your own domain and Debian5srv1 to the name of your Debian server.

Step 1:  Update / Upgrade your Debain setup

apt-get update && apt-get upgrade

Step 2: Install the following packages:

apt-get install krb5-config krb5-user libkrb53 libpam-krb5
samba-common samba winbind smbclient

Step 3:  Create a backup of the krb5.conf file.

mv /etc/krb5.conf /etc/krb5.conf.org

edit the /etc/krb5.conf file with you favorite editor (nano or vi /etc/krb5.conf):

[logging]

default = FILE:/var/log/krb5.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmin.log

[libdefaults]

default_realm = ICT-FREAK.LOCAL
dns_lookup_realm = false
dns_lookup_kdc = false
clock_skew = 300
ticket_lifetime = 24h
forwardable = yes

[realms]

ICT-FREAK.LOCAL = {
kdc = dc01.ICT-FREAK.LOCAL
admin_server = dc01.ICT-FREAK.LOCAL
default_domain = ICT-FREAK.LOCAL
}

Step 4: Check if you can Authenticate a user against the Active Directory

debian5srv1:~# kinit administrator
Password for administrator@ICT-FREAK.LOCAL:

Step 5: Create a backup of the krb5.conf file.

mv /etc/samba/smb.conf /etc/samba/smb.conf.org

edit the /etc/samba/smb.conf file with you favorite editor (nano or vi /etc/samba/smb.conf):

[global]

workgroup = ICT-FREAK
realm = ICT-FREAK.LOCAL
load printers = no
preferred master = no
local master = no
server string = fileserver
password server = <ip-address from your DC>
encrypt passwords = yes
security = ADS
netbios name = debian5srv1
client signing = Yes
dns proxy = No
wins server = <ip-address from your DC>
idmap uid = 10000-20000
idmap gid = 10000-20000
winbind separator = +
winbind enum users = Yes
winbind enum groups = Yes
winbind use default domain = Yes
auth methods = winbind

Step 6: Start Winbind and test the connection

/etc/init.d/winbind start

You can query the AD with the command wbinfo. The –u parameter returns all users. The –g parameter returns all groups.

debian5srv1:~# wbinfo -u
administrator
guest
support_388945a0
krbtgt

debian5srv1:~# wbinfo -g
BUILTIN+administrators
BUILTIN+users
helpservicesgroup
telnetclients
domain computers
domain controllers
schema admins
enterprise admins
cert publishers
domain admins
domain users
domain guests
group policy creator owners
ras and ias servers
dnsadmins
dnsupdateproxy
dhcp users
dhcp administrators
wins users

Step 7: Add the Debian box to the Windows domain

debian5srv1:~# kinit administrator
Password for administrator@ICT-FREAK.LOCAL

debian5srv1:~# net ads join -U administrator
Joined ‘debian5srv1’ to realm ‘ICT-FREAK.LOCAL’

Step 8: Now tell PAM that samba requires authentication and account from winbind. Add the following lines to /etc/pam.d/samba

auth required /lib/security/pam_winbind.so
account required /lib/security/pam_winbind.so

We also need to edit the /etc/nsswitch.conf file so it will look like this:

passwd: compat winbind
group: compat winbind
shadow: compat

Test the new settings with: getent passwd If everything is configured as it should be, you’ll see the AD users.

Step 9: Create a share. First we need to create a folder

mkdir –p /data/share

Change the permissions so the folder is writable

chmod 777 /data/share

Open the /etc/samba/smb.conf file and paste the following lines:

[Share]
comment = Test Share
read only = no
path = /data/share
valid users = @"ICT-FREAK+domain users"

Restart the Samba service via:

/etc/init.d/samba restart

Step 10: Test the new share. Go to your Windows box and browse to the Debian box via \\debian5srv1 

If everything is configured as it should be, you will see the following screen:

image

 

Sources:
http://www.simsonlai.org/samba-and-active-directory-authentication/
http://rubenleusink.com/debian-samba-filesharing-with-microsoft-active-directory-authentication-2008-10-07/

Script: Powershell script for changing the AD Home Dir and Drive


image 

Stel je bent midden in een migratie naar een andere fileserver of naar bijvoorbeeld een NetApp filer. Daarnaast wil je ook alle Home directory’s migreren. Dit houdt in dat je ook de Active Directory moet aanpassen.  Dit kun je op verschillende manieren doen. Ik heb gekozen om eens te kijken naar de Quest ActiveRoles addin voor Powershell en dat bleek behoorlijk krachtig te zij, zoals je kunt zien in het onderstaande scriptje:

image

Voordat je dit script kunt gebruiken heb je een PC nodig die lid is van het domain, PowerShell en de Quest AD cmd-lets geïnstalleerd heeft. Daarna kun je het script als volgt uitvoeren:

PS Scriptdir> .\Change_Home_Dir_drive.ps1

image

Daarna kun je in de Active Directory nakijken of het script succesvol heeft gelopen.

image