Customising a Cisco 79xx IP Phone: directory services

This content is 16 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

I’m still working on customising the the Cisco 7940 I use with SIP firmware for VoIP calls and one of the items that’s now working well is the directory services functionality.

At the most basic level, the directory_url directive may be set in one of the SIP configuration files (either SIPDefault.cnf or SIPmacaddress.cnf), for example:

directory_url: ”http://webserver/directory.xml”

The contents of the directory.xml file are actually quite simple:

<CiscoIPPhoneDirectory>
  <Title>IP Telephony Directory</Title>
  <Prompt>People reachable via VoIP</Prompt>
  <DirectoryEntry>
    <Name>Bob</Name>
    <Telephone>1234</Telephone>
  </DirectoryEntry>
  <DirectoryEntry>
    <Name>Joe</Name>
    <Telephone>1357</Telephone>
  </DirectoryEntry>
  <DirectoryEntry>
    <Name>Operator</Name>
    <Telephone>0</Telephone>
  </DirectoryEntry>
</CiscoIPPhoneDirectory>

The trouble with this is that it’s just a static file. If I have a large directory, then I need to keep it up-to-date. That’s where a directory service comes into play. The Open 79xx XML Directory looks useful but it’s another application to install and manage on my infrastructure. I already have a directory (Microsoft Active Directory), so I thought it would be great if a piece of code could query the AD and output the file in a format that the 7940 understands.

Luckily I found such a piece of code, courtesy of a message posted to the Asterisk Users forum back in 2004 by Jeff Gustafson:

<?php
$ds=ldap_connect("ldapserver");  // must be a valid LDAP server!

if ($ds) {
  $r=ldap_bind($ds);  // this is an "anonymous" bind, typically read-only access

  $sr=ldap_search($ds, "ou=People,dc=domainname,dc=com",
"telephoneNumber=*");
  echo "<CiscoIPPhoneDirectory>\n";
  echo "<Title>IP Telephony Directory</Title>\n";
  echo "<Prompt>People reachable via VoIP</Prompt>\n";

  $info = ldap_get_entries($ds, $sr);

  for ($i=0; $i<$info["count"]; $i++) {
    echo "<DirectoryEntry>\n";
    echo "<Name>" . $info[$i]["cn"][0] . "</Name>\n";
    echo "<Telephone>" . $info[$i]["telephonenumber"][0] .
"</Telephone>\n";
    echo "</DirectoryEntry>\n";
  }

  echo "</CiscoIPPhoneDirectory>";
  ldap_close($ds);

} else {
  echo "error";
}
?>

Jeff’s code is great (my PHP skills are certainly not good enough to have written this myself) but Active Directory has an attribute for IP phone numbers (ipPhone), so I made a couple of edits to change the phone prompts and to make the LDAP query search on the ipPhone attribute:

<?php
$ds=ldap_connect("domaincontroller.domainname.tld");  // must be a valid LDAP server!

if ($ds) {
  $r=ldap_bind($ds); // this is an "anonymous" bind, typically read-only access

  $sr=ldap_search($ds, "ou=directorycontainer,dc=domainname,dc=tld",
"ipphone=*");
  echo "<CiscoIPPhoneDirectory>\n";
  echo "<Title>IP Telephony Directory</Title>\n";
  echo "<Prompt>Active Directory Users</Prompt>\n";

  $info = ldap_get_entries($ds, $sr);

  for ($i=0; $i<$info["count"]; $i++) {
    echo "<DirectoryEntry>\n";
    echo "<Name>" . $info[$i]["displayname"][0] . "</Name>\n";
    echo "<Telephone>" . $info[$i]["ipphone"][0] .
"</Telephone>\n";
    echo "</DirectoryEntry>\n";
  }

  echo "</CiscoIPPhoneDirectory>";
  ldap_close($ds);

} else {
  echo "error";
}
?>

I still needed a couple of tweaks to get this working though – not to the script, just to: the webserver I used to serve it; to Active Directory; and finally to the phone configuration.

First up, you need a web server with PHP installed (I used PHP 5.2.6 on IIS 6.0). This also needs the LDAP extension to be enabled by uncommenting extension=php_ldap.dll in php.ini. The extensions folder (e.g. C:\phpinstallationfolder\extensionfolder) also needs to be appended to the %path% system variable.

The script is actually for a generic LDAP directory (nothing wrong with that) but recent versions of Active Directory do not allow anonymous access by default. Daniel Petri has a detailed article on anonymous LDAP operations in Windows 2003 AD and that gave me the information that I needed to open up the parts of the directory that I wanted the script to read – basically: setting the 7th bit of the dsHeuristics flag on CN=Directory Service,CN=Windows NT,CN=Services,DC=domainname,DC=tld to 2 on the forest root domain; waiting for replication to complete; granting ANONYMOUS LOGON read access on the appropriate objects and List Contents access on the OU that contains the object(s). Alternatively, it should be possible to edit the script to use an authenticated logon (and sorting by surname wouldn’t go amiss either) but it’s getting late now and that will have to wait for another day! In the meantime, Geoff Jacobs’ post on creating a personal directory for the Linksys SPA942 using LDAP should provide some inspiration.

Last, but by no means least, the directory_url directive needs to be edited to reflect the name of the PHP script instead of the original static XML, for example:

directory_url: ”http://webserver/directory.php”

In order to pick up the changes, the phone will need a reset.

Now, when I access the external directory from the phone using the directory button and option 5, I’m presented with a list of contacts from Active Directory. Furthermore, because the web server uses dynamic content, the details are as current as the directory server that it refers to.

Account lockouts and disconnected remote connections

This content is 16 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

For the last week or so, my colleagues have suffered an increasing amount of profanity as I’ve struggled with account lockouts on our Active Directory. I honestly nearly threw my notebook PC across the room last Wednesday.

I’d had my password reset twice and the account lockout flag removed about 7 or 8 times but I didn’t really get the answer that I needed when I asked our (offshored) IT helpdesk what might be causing the problem (for example, were there any AD synchronisation issues that they were aware of). After giving up on the helpdesk, I circumvented the proper support channels and dropped an e-mail to one of the administrators, who helpfully pointed me in the direction of another support team with the tools to diagnose the source of my lockouts and said it tends to be a disconnected terminal session or a software update program (e.g.from Adobe) using old credentials (e.g. to access the Internet via our proxy servers) that causes the lockout.

Sure enough, the problem was traced to a terminal server – and I did have a disconnected session there. Since resetting that session, the account lockouts have gone away and my access to e-mail, intranet, internal websites, Internet proxy servers, etc. has been restored.

My first inclination was to blame the infrastructure – and in this case it turned out to be a user error (or “a layer 8 problem”, as I like to refer to such things)… even so, I thought the experience might be useful for someone else who is getting frustrated by near-continuous account lockouts.

Xtremely Technical Seminars

This content is 17 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

If I was asked to name an industry expert on Active Directory, one of the names that would come to mind consultant is John Craddock of Kimberry Associates, who I have seen present with Sally Storey many times on behalf of Microsoft. John has formed a new company called XTSeminars (Xtremely Technical Seminars) and I’m pleased to see that John and Sally are working with another speaker whom I hold in high regard – Rafal Lukawiecki of Project Botticelli.

XTSeminars are a business venture – and as such the events are chargeable; however, based on previous events I’ve seen John and Sally present, I have absolutely no issue in recommending them – as they suggest:

Attend one of the seminars and not only will you rapidly get the real details but also an XTSeminars workbook packed with useful tips and techniques and a DVD with narrated videos of all the demos. Attend the seminars as a sponge and absorb the knowledge. All for a fraction of the cost of working with a lead consultant!

Definitely worth a slice of the training budget for anyone looking to improve their in-depth technical knowledge of key Microsoft technologies.

Some more on using Active Directory for Linux/Mac OS X user authentication

This content is 17 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

Last year I wrote a post about using Microsoft Active Directory (AD) to authenticate users on a Red Hat Enterprise Linux (RHEL) computer (and a few weeks back I followed it up for Mac OS X). This week, I’ve been re-visiting that subject, as I built a new FTP server at home and wanted to use AD for authentication.

In the process, I came across a couple of extra resources that might be useful:

As I was using an almost-new AD (not the old one that I have been tweaking for years), I found that RHEL5 (and Mac OS X 10.5) did not need me to disable digital signing of communications as recent versions of Samba include client side signing. The Samba documentation suggests that it is necessary to set client use spnego = yes in smb.conf when authenticating against a Windows Server 2003 domain controller but I did not find that to be the case with Samba v3.0.23c and Windows Server 2003 R2 with SP2 (perhaps that is the default?).

The following notes may also be useful:

  • SSH does not require any further configuration but if Samba is configured to use the default separator for domainname and username (\) then you will need to escape it – so the connection command would be ssh domainname\username@hostname.
  • This also works for FTP (ftp domainname\username@hostname) but I’ve not found a way to make a simple ftp hostname use AD for authentication.
  • Even though Linux/Unix usernames are case-sensitive, Windows ones are not, so any combination of lower and upper case is valid for domainname\username. Passwords do need to be entered in the correct case (as in Windows).

Using Active Directory to authenticate users on a Mac OS X computer

This content is 17 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

One of the projects that I’ve been meaning to complete for a while now has been getting my Mac OS X computers to participate in my Active Directory (AD) domain. I got Active Directory working with Linux – so surely it should be possible to repeat the process on a system with BSD Unix at the core? Yes, as it happens, it is.

Before I explain what was necessary, it’s probably worth mentioning that the process is not the same for every version of OS X. As explained in a Microsoft TechNet magazine article from 2005, early implementations of OS X required schema changes in Active Directory in order to make things work. Thankfully, with OS X 10.4/10.5 (and possibly with later versions of 10.3 – although I haven’t tried), schema changes are no longer necessary.

By far and away the best resource on this subject is Nate Osborne’s Mac OS/Linux/Windows single sign-on article at the Big Nerd Ranch weblog. This told me just about everything I needed to know (with screenshots) but, crucially, when I tried this over a year ago on my OS 10.4 system I could not get the Mac to bind with Active Directory. This was despite having disabled digital signing of communications (not required for OS X 10.5) and it turned out that the problem is the internal DNS domain name that I use which uses a .local suffix. As described in Microsoft knowledge base article 836413, OS X treats .local domains as being Rendezvous/Bonjour hosts and needs to be told what to do. There is an Apple article that describes how to look up .local hostnames using both Bonjour and DNS; however I’m not sure that’s what fixed it on my OS X 10.5.2 system. My TCP/IP, DNS and WINS settings were all being provided by DHCP and, even though I added local to the list of search domains, it was the second listed domain (after the DHCP-suppled entry) and successful binding seemed to occur after I had pinged both the domain name and the domain controller (by name and by IP address) and performed an nslookup on the domain name. Another thing that I considered (but did not actually need to do) was to create a reverse lookup (PTR) record in DNS for the domain name. Retrying the process and binding to a domain with a .co.uk suffix presented no issues at all.

Nate’s article is for OS X 10.4 (Tiger), and having got this working in OS X 10.5.2 (Leopard), I thought I post a few more screenshots to illustrate the process:

  1. First of all, open the OS X Directory Utility and Show Advanced Settings. Switch to the Services view and ensure that Active Directory is selected, then click the button with the pencil icon to edit the settings:
    Mac OS X 10.5 Directory Utility - Services
  2. Enter the domain name (home.local) in my case and computer name. In the Advanced Options, I left the user experience items at their defaults (more on that later):
    Mac OS X 10.5 Directory Utility - Active Directory User Experience options
  3. Switching to the administrative options reveals some more settings that are required – I checked the box to enable administration by the Domain Admins and Enterprise Admins groups, but others group or user accounts can be added as potential computer administrators:
    Mac OS X 10.5 Directory Utility - Active Directory Administrative options
  4. Click the bind button and, when prompted, supply appropriate credentials to join the Macintosh computer to the domain (i.e. AD credentials). This is the point where the location of the computer account is defined.
    Mac OS X 10.5 Directory Utility - Active Directory authentication
  5. If you receive an error relating to an invalid domain and forest combination being supplied, this is likely to be a DNS issue. Check that DNS name resolution is working (using the OS X Terminal utility and the ping or nslookup commands) and note my earlier comments about support for .local domain name suffixes – you may need to follow Apple’s advice to add local to the list of search domains:
    Mac OS X 10.5 Directory Utility - Invalid Domain error message
    Mac OS X 10.5 Network Preferences - DNS settings
  6. Once successfully bound to Active Directory, the group names for administration of the local computer will be expressed in the format domainname\groupname. The system event log on the domain controller that processed the directory request will also show a number of account management events, as the computer account is created and enabled, then the password is set and the associated attributes changed (password last set and service principal names):
    Mac OS X 10.5 Directory Utility - Active Directory Administrative options
  7. In the OS X Directory Utility, Click OK, and move to the Directory Servers view – is all is well then the domain name will be listed along with a comment that the server is responding normally:
    Mac OS X 10.5 Directory Utility - Directory Servers
  8. Active Directory/All Domains should also have been added to the Authentication and Contacts views in the Search Policy:
    Mac OS X 10.5 Directory Utility - Search Policy Authentication
    Mac OS X 10.5 Directory Utility - Search Policy Contacts

Following this, it should be possible to view AD contacts in the Directory and also to log on using an AD account (in domainname\accountname format). Although this worked for me, I was having some issues (which I suspect were down to a problematic AirPort connection). Once I had switched to wired Ethernet, I was able to reliably authenticate using Active Directory, although I did not re-map my home drive to the network (Leopard’s SMB/CIFS support is reported to be problematic and I felt that can of worms could stay closed for a little longer until I was comfortable that AD authentication was working well). Instead, and because my computer is a MacBook, so will often be disconnected from my network, I changed the User Experience options for Active Directory to use a mobile account – effectively creating a local account on the MacBook that is mapped to my domain user:

Mac OS X 10.5 Directory Utility - Active Directory User Experience options

At the next logon, I was prompted to create a mobile account and once this was done, I could access the computer whilst disconnected from the LAN, using the using the AD credentials for the last-logged-on user.

One more point that’s worth noting – if you have existing local accounts with the same name as an AD account, the permissions around user account settings get messy, with the AD logon resulting in a message that there was a problem creating your mobile account record and the local logon reporting that there was a problem while creating or accessing “Users/username“.

That’s all I needed; however I did compile a list of links that might be useful to others who come across issues whilst trying to get this working (perhaps on another version of OS X):

Performing an Active Directory Health Check

This content is 17 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

A few months ago, I was in a situation where I needed to perform a health check on a customer’s Active Directory (AD) infrastructure in preparation for guiding them through the process of migrating directory objects between forests. I’ve worked with AD for years – and am reasonably familiar with the various utilities – but didn’t really have a formalised method for reviewing its health and the political climate was such that I didn’t want to be the one who had missed an obvious diagnostic (no pressure there then!).

Then I found an eBook which turned out to be a fantastic investment – Andrew Abbate’s Digital Shortcut to Performing an Active Directory Health Check. Published by SAMS and supplied in Adobe PDF format (protected with digital rights management), this book gave me a refresher course on the tools and their use, then describes how to carry out the health check, interpret the data, and fix the problems. Sure, it won’t tell you everything you need to know – but it certainly gave me enough to apply the rest of my skills and knowledge to get to the bottom of the issues we were experiencing.

This eBook is available via the Safari online library; however googling also turned up copies available for purchase and download from a variety of online stores – I bought a copy for $9.99 at eBookMall.

Migrating passwords with the Active Directory Migration Tool

This content is 17 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

I’ve spent most of this month working with a customer who is consolidating various Active Directory forests into a single domain. We didn’t use any third party tools – just the standard Microsoft utilities, i.e. Active Directory Migration Tool (ADMT) v3 and Exchange Migration Wizard (one of the Exchange Server 2003 deployment tools) – but they seem to do the job.

As migrating several hundred users to new accounts (with new passwords) would cause a huge number of support calls, I wanted to get the ADMT password migration DLL working. This took some time, but with the help of my enterprise support colleagues (effectively a PSS call), we found a way through. This is what was required:

(For reference, both the source and target domains were in Windows Server 2003 domain and forest functional mode, running Windows Server 2003 with a mixture of service packs 1 and 2.)

  1. Make sure that there is a trust in place between the source and target domains.
  2. Install ADMT by running admtsetup.exe and follow the installation wizard on the computer that will be used for the migration (I used a domain controller in the source domain but ideally you would have dedicated computers for migration activities and it seems logical that this should be in the target domain).
  3. If not already created by ADMT, create a new domain local group called domainname$$$. This group must be empty, and is required in order to migrate the sIDHistory information between source and target accounts.
  4. On the domain controller that will be used to export the account information (usually the DC holding the PDC Emulator operations master role for the source domain), create/set a value of 1 for a DWORD registry key called TcpipClientSupport in HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\LSA\.
  5. In both the source and target domains, ensure that success and failure auditing is enabled for account management.
  6. On a computer with ADMT installed, create a password encryption key for each source domain, by shelling out to a command prompt and entering the following commands:
    cd %systemroot%\ADMT
    admt key /option:create /sourcedomain:domainname /keyfile:filename.pes

    (the domainname can be specified in NetBIOS or DNS format.)
  7. On the domain controller in the source domain that holds the PDC Emulator operations master role, connect to the computer with ADMT installed (e.g. via the c$ administration share) and access the %systemroot%\ADMT\PES folder.
  8. Run pwdmig.exe to install the ADMT Password Migration DLL and follow the installation wizard. During the installation, supply the password encryption (.PES) file that was created earlier.
  9. This is the step that’s not in the instructions – even though the password encyption file was supplied during the installation of the ADMT Password Migration DLL, it still needs to be imported manually on the PDC Emulator, by shelling out to a command prompt and entering the following commands:
    cd %systemroot%\ADMT
    admt key /option:import /sourcedomain:domainname /keyfile:filename.pes
  10. On the domain controller that will be used to export the account information, create/set a value of 1 for a DWORD registry key called AllowPasswordExport in HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\LSA\. Note that this key constitutes a security risk and should only be enabled during the period of migration.
  11. Restart the computer with the ADMT Password Migrator DLL installed.
  12. Start the Password Export Server service.

Most of this is exactly as per the documentation – the main difference is the need to manually import the password encryption file. Without this, I was receiving the following message:

Error
Unable to establish a session with the password export server. The source password export server and the target server do not have the same encryption key for the source domain.

Finally, what permissions are required? I used Local System for the Password Export Server service. For everything else, I used an account which had been created in both forests with identical passwords and which was a member of the Domain Admins group. That’s a little excessive, and best practice would involve using an account with the minimum required permissions. Basically, an account is required that is:

  • Domain administrator in the source domain.
  • Local administrator on the computer on which ADMT is installed.
  • Delegated permissions on OUs that are targets for resource migration in the target domain, including the extended right to Migrate SID History (visible in the Security for an object using the Advanced Features view in Active Directory Users and Computers).

Further advice can be found in the ADMT v3 Migration Guide.

Active Directory and relative identifiers

This content is 17 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

Last night, I wrote a post about how a little logical thinking was required in order to resolve some issues with the dcdiag.exe utility from the Windows Server 2003 Support Tools.

Since then, I’ve been examining the dcdiag test results and was a little alarmed to find that two of the domain controllers (DCs) for the domain that I intend to migrate several hundred users into were reporting a lack of available RIDs:

Starting test: RidManager
   * Available RID Pool for the Domain is 17352 to 1073741823
   *
domaincontrollername.domainname.tld is the RID Master
   * DsBind with RID Master was successful
   * rIDAllocationPool is 14352 to 14851
   * rIDPreviousAllocationPool is 12352 to 12851
   * rIDNextRID: 12849
   * Warning :There is less than 1% available RIDs in the current pool
   …………………….
domaincontrollername passed test RidManager

For anyone who doesn’t appreciate the potential significance of this, relative identifiers (RIDs) are necessary in order to create new Active Directory objects.  Because Active Directory uses a multi-master model, any DC can create an object, which is then replicated between the various DCs in the organisation.  Objects are actually identified by their SID, part of which includes the domain identifier, and part of which is the RID.  In order to maintain uniqueness, the generation and allocation of RIDs is controlled by the DC holding the RID Master role for the domain, allocating pools of 500 (by default) RIDs to DCs for use when generating the SIDs for new objects.  Still with me?  Microsoft knowledge base article 305475 has more details.

Active Directory DCs (at Windows 2000 SP4 and later revisions) request a new RID pool from the RID master once the pool is 50% depleted, so 1% of available RIDs concerned me somewhat.  Other tests had confirmed that replication was working, and switching the RID Master role to another DC didn’t appear to make any change.  I also checked to see that there were no duplicate SIDs in the domain.  As it happens, everything was working normally but the labels, and the warning, are very confusing. This is what I found:

  • rIDPreviousAllocationPool is not, as the name suggests, the last pool that was used – it’s actually the RID pool that is currently being used.   So, in the example above, 12352 to 12851 is the list of RIDs currently being allocated. When this becomes exhausted (rIDNextRID gives an indication of how soon this will occur), Windows copies rIDAllocationPool into rIDPreviousAllocationPool and starts using the new RIDs as needed. There is a global RID pool size limit that the RID Master can allocate from (the Available RID Pool).
  • rIDAllocationPool is the next batch of RIDs to be used (supplied by the RID Master).  In this case, 14352 to 14851 will be the next batch of RID numbers (500 in the pool) for this DC.  This is generated automatically via a request to the RID Master once the pool is 50% depleted.
  • rIDNextRID is the last RID allocated (not the next one to be allocated).  So the next object to get created in the example above will get RID 12850.

I tested this by creating some new users and running further tests with dcdiag.exe, observing the DC reach the end of the pool and then start using the next pool (originally called rIDAllocationPool):

Starting test: RidManager
   * Available RID Pool for the Domain is 17352 to 1073741823
   *
domaincontrollername.domainname.tld is the RID Master
   * DsBind with RID Master was successful
   * rIDAllocationPool is 14352 to 14851
   * rIDPreviousAllocationPool is 12352 to 12851
   * rIDNextRID: 12851
   * Warning :There is less than 0% available RIDs in the current pool
   …………………….
domaincontrollername passed test RidManager

Starting test: RidManager
   * Available RID Pool for the Domain is 17352 to 1073741823 
   *
domaincontrollername.domainname.tld is the RID Master 
   * DsBind with RID Master was successful
   * rIDAllocationPool is 14352 to 14851
   * rIDPreviousAllocationPool is 14352 to 14851
   * rIDNextRID: 14352
   …………………….
domaincontrollername passed test RidManager

Once I have created another 249 or so users, I should see a new rIDAllocationPool generated.

Screenshot showing the RID as part of a SID in the additional account informationJust to be sure that I understood this fully, I installed acctinfo.dll, after which I could clearly see the RID at the end of the SID for the test user account (when viewing the Additional Account Info tab on the user properties in Active Directory Users and Computers).

In short, if you see a message about less than a certain percentage of RIDs in the current pool, don’t worry about it (as long as rIDAllocationPool is different to rIDPreviousAllocationPool)!  The pool will gradually be used until it reaches 0% and tips over into the next allocation.  The problem is the confusing language used (rIDAllocationPool should really be rIDNextAllocationPool, rIDPreviousAllocationPool should really be rIDCurrentAllocationPool and rIDNextRID should be rIDPreviousRID).

Installing Microsoft Dynamics CRM without domain administrator rights

This content is 17 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

I recently inherited the task of designing the infrastructure for a Microsoft Dynamics CRM 3.0 implementation. After being briefed by the consultancy partner that we are using for the application customisation and reading Microsoft’s implementation guide I was fairly comfortable with the basic principles but I was also alarmed that the product seems to require installation to be carried out using an account with Domain Admins permissions. There’s no way that I will be granted those rights on our corporate Active Directory (and nor should I be) – too many applications seem to require elevated permissions for service accounts and it makes life very difficult when trying to define a delegation policy for Active Directory administration.

Regardless of the assurances I was given that Domain Admins rights are only required to carry out the installation (and subsequent updates) and that the account can be relegated to a standard domain user afterwards, I felt that there must be a way around this – surely the groups that the CRM installation creates can be pre-staged somehow, or that a organizational unit can be created with delegated rights to create and manage objects?

It seems the answer to my question is yes – I’ve now been pointed in the direction of Microsoft knowledge base article 908984 which describes how to install Microsoft Dynamics CRM 3.0 as a user who is not a domain administrator by using the minimum required permissions.

Fine grained password policies for Windows Server 2008 Active Directory Domain Services

This content is 17 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

Another new feature in Windows Server 2008 Active Directory Domain Services is that (at long last) it’s now possible to apply multiple password policies within a single domain using a new feature called fine grained password policies. Now PINs can be used for mobile device access and complex passwords for conventional form factor devices without requiring separate domains, third party software or writing a custom password filter DLL.

The fine grained password policies are user and group based (i.e. not per-OU – in order to avoid extra domain load during login) and multiple policies can be applied; however, the new functionality involves a complex administrative process and there is no GUI yet (although the password settings container can be found if Advanced Features are enabled in Active Directory Users and Computers). Fortunately, Joe Richards has written PSOMgr (a command line tool to manage fine grain password policy password settings objects) and Christoffer Andersson has a similar tool with MMC/PowerShell interfaces.