Installing and Configuring Microsoft System Center Configuration Manager

I know that I've left the Active Directory series with barely enough info to get you going with Linux, but real life priorities are intervening at work, and I don't have the time right now to document the next step in the Linux integration, which will be getting service level authentication working with Kerberos for stuff like NFS. It's coming soon, I promise.

In the meantime, I'm setting up another Microsoft System Center Configuration Manager server -- for obvious reasons, I won't use the full title again, and will call it ConfigMgr or SCCM as the mood strikes me -- and I thought I'd do a quick write-up on that while I'm at it; while this installation is going smoothly (fingers crossed) I think I reinstalled my original ConfigMgr server four to six times before getting it right.

ConfigMgr Server Setup

To keep things simple, I've kept all of my ConfigMgr-related features on one server -- the Certificate Server, SQL Server, IIS, and all of ConfigMgr's own functions are on one box. It seems to handle the load just fine, though the admin interface can be a little sluggish at times when dealing with heavy database interaction.

First of, there's a question of the version of Windows to use. While I'm almost always inclined to use the latest version of software that is available, my experiences a year or so ago with ConfigMgr on Windows Server 2008 were less than stellar. I spent quite a lot of time running into inexplicable dead ends, and time to waste is not a luxury I have right now. So I've decided to continue with Windows Server 2003 R2, which is the next best thing. Once all my new systems are up in production, I'll go back to the lab and see if the situation with ConfigMgr on 2008 has improved.

The edition of 2003 also matters -- you need at least one Enterprise Edition server in your domain running AD Certificate Services, or you won't be able to even install ConfigMgr without a lot of ugly hacks -- it requires a custom certificate template for the SCCM site servers, and Standard Edition won't let you use custom templates. Also, though I installed 2003 R2, I didn't ever actually go through the R2 specific features; I didn't need them on this particular server.

One the system is built, joined to a domain, and patched, I installed IIS. BITS and WebDAV are important requirements, so make sure to install them. Once these were installed, I went back into the Windows Component wizard and installed Certificate Services. I set it up as an enterprise root CA -- if you're deeply concerned about the security of your PKI, you probably don't want the root CA to be on a production system, but rather on a box which stays offline and physically secure. However, the only purpose of this particular PKI is to provide security for my ConfigMgr setup, so I didn't see much point in investing significant resources in making it more secure than the overall Active Directory domain which it plays a comparatively small part in. Next I configured the CA and enrolled the ConfigMgr server for its Site Server certificate. This is a bit of an arbitrary and tedious process, so I'll just point you to the KB article that describes the process. The IIS server should also be configured with a certificate to use for https:// communications -- I used a commercial certificate, but you can also use your local PKI to create one. If you choose the latter, domain clients will automatically trust the cert, but non-domain machines will not. This is probably not a big deal, since any non-domain ConfigMgr clients will have to have the PKI root certificate installed anyway, but it's worth noting in case you're using standalone systems with the web interface.

The next thing to install is SQL Server; I used 2005, again primarily because of a lack of testing time; when I first installed ConfigMgr, 2005 was the latest version, so I know that it works. Service Pack 2 is definitely required, and there's a hotfix that I needed; your mileage may vary. WSUS must also be installed, although it doesn't have to be used for ConfigMgr to deploy patches; I installed it along with SP1, and then took a break from software installations to catch up on patches through Windows Update; a couple of reboots later I was ready to keep forging on ahead, and we were finally done with prerequisites and ready to tackle ConfigMgr itself.

Well, almost ready; technically, extending the AD schema to enhance ConfigMgr support is not required, but it does improve the efficiency of your site, so I decided to go for it; Microsoft has several TechNet articles with more information on why and how to extend the schema -- it was completely painless in my case. There wasn't much to the actual SCCM installer once I'd gotten all of the prereqs out of the way -- I chose to do a native mode installation, enabled all agents except for Network Access Protection (again, a feature I haven't had time to experiment with in a lab), and that was pretty much it. once it had the information it needed, the installer took quite a while to run, so I suggest locking the console and stepping out for a bit of your preferred caffeine source at this point.

After the install itself, I again ran Windows Update, and rebooted, then started up the New Site Roles wizard. A couple of things to keep in mind -- the FQDN for inter- and intra- site communication needs to match the Active Directory domain; this might not be an issue for you, but in my environment most of our servers have internet-facing DNS addresses which are shorter that their fully-qualified AD DNS domain. Since the local PKI will be securing the communications, the AD domain name is the one which will be used, and mismatches definitely won't be accepted. I also instructed the wizard to "use this server as the active software update point", and checked the boxes for the following roles, keeping with my "one server to rule them all" philosophy:

• Server locator point
  
• Reporting point
  
• Software update point
  
• Fallback status point
  

The next configuration step was to enable inter- and intra- site communication on both the Management Point and Distribution Point. I also created two domain accounts -- one user account with minimal access, which ConfigMgr uses to authenticate when pulling data from the server (the Network Access Account) and one with domain admin which is used to do automated installs; strictly speaking, this account might only need local admin on all of your systems, but it seemed easier to me just to go with domain admin and not worry about the one-off problems that might occur with systems not getting the memo about the account's access. I also added the ConfigMgr server's computer account (SERVERNAME$) to the domain admins group -- this allows the server, which runs as LocalSystem, to do pretty much anything it wants. This may seem scary, but again, keep in mind that as long as you practice the same level of physical and electronic security measures on this server as you do on your domain controllers, you're really not introducing a new level of vulnerability, you're just confronting it from a different angle. Like your domain controllers, this server now holds the keys to your electronic kingdom, so treat it with respect and care! The last set of ConfigMgr settings I had to muck with was under the Software Update Point properties:

• Active software point on site server
  
• Allow both inter- and intra- communication
  
• Checkmark "All Classifications"
  
• Enable synchronization on a schedule
  
• Uncheck all languages except English
  

Obviously the last item was specific to my locale; adjust accordingly. At this point, if you've enabled client certificate enrollment (as described in the KB article above) and you enable Active Directory discovery and some form of client installation (I do scheduled pushes through ConfigMgr) you should start to get domain clients joining your system.

Manual Client Installation

Manual client installation is a bit of a hassle, but it's great for supporting users who don't live on your domain, whether they be home users, laptops, or for little pockets of machines that have to be managed but just can't be in your primary Active Directory hierarchy.

Before you try to sign up clients, you'll need to get them into your PKI; the normal Computer certificate isn't ideal, since it doesn't allow you to specify the client's name. Mimic the steps required to create the ConfigMgr Site Server certificate template, but don't make any changes to the template other than setting the Subject Name to be supplied in the request.

The first thing to do on each client is to get the PKI root certificate into your computer's local certificate store. If you use the local PKI for IIS on the ConfigMgr server, then simply browse to https://[fqdn]/certsrv, examine the certificate chain that's presented, and install the Root CA certificate. Once this is done, log in to the address you just visited with a domain admin account, and create a certificate using the template you just set up above. Make sure that the subject name is unique -- it doesn't have to be the FQDN of the system, nor even to be formatted as a DNS name, but if two systems get certificates with the same subject name, only the most recent system will be able to talk to ConfigMgr. Anyhow, once the certificate is installed, get access to the \SMS_SITE\Client folder -- via CD/USB drive, network share, whatever, open a command prompt in the folder, and run the following command:

ccmsetup /forcereboot /noservice /native:FALLBACK SMSSITECODE=[sitecode] CCMHOSTNAME=[server.fqdn] FSP=[server.fqdn]

Be prepared for the system to reboot itself with no warning -- if this is unacceptable, omit the /forcereboot switch, but remember that the ConfigMgr client probably won't run until the system is rebooted.

Part 3: Windows Server 2008 Active Directory Kerberos and LDAP Integration -- Linux User Account Setup

This is the third post in a series on AD integration; the previous post deals with Active Directory installation and configuration

The Linux client I've chosen for the test lab is a 64-bit Fedora 10 installation. This distribution was chosen for its compatibility with my deployed systems. Like the Windows 2008 server, this machine is a VM, and the installation was a pretty generic GUI install. My deployed systems are installed via kickstart and managed with Puppet, but to maintain control over the environment, all test lab installation and configuration was done manually.

DHCP and DNS

Once the initial installation was done, I logged in as root and began to configure the system. Although most of my client systems are static IPs, I've decided to try using DHCP. The first configuration change I've made is to set the hostname in /etc/sysconfig/network, adding a line:

HOSTNAME=<client>

and to ask the system to send it's hostname with DHCP requests in /etc/sysconfig/network-scripts/ifcfg-eth0:

DHCP_HOSTNAME=<client>

After setting both of these, I rebooted the system to have it pick up the new name. Once the system was back up, I logged in to verify it's hostname, and checked on the DNS server to verify that it was registered in

Network Time Protocol

Kerberos requires clients to be reasonably closely synchronized to the server; NTP is the obvious choice for this function, as it's enabled by default in Windows server, and can be set up on fedora clients with the following commands:

echo 'server <ad>' > /etc/ntp.conf
chkconfig ntpd on
service ntpd start

Shortly after turning ntpd on, notifications should appear in /var/log/messages regarding the state of time synchronization.

In the test lab, I found that the NTP clients didn't respond well to NTP synchronization; this is a known issue with VMware virtual machines, so I've disabled NTP and rely on VMware tools to keep the time sync'd.

OpenLDAP

OpenLDAP configuration is handled by /etc/ldap.conf, which so far has been the trickiest bit of configuration to figure out, so mention of a couple of troubleshooting steps is in order. First, I found it useful to install the openldap-clients package, which includes the ldapsearch utility that can be used for making arbitrary queries. Secondly, appending the line

debug 1

to /etc/ldap.conf provides a wealth of information that has been useful in troubleshooting connections -- the output is sent to your terminal when using 'finger', 'id', or 'getent'. Higher debug levels can be chosen, but for my purposes 1 was usually sufficient.

But back to /etc/ldap.conf; mine looks like this:

uri ldaps://<ad server>:636/

base dc=fqdn,dc=com

ssl start_tls

ssl on

tls_cacertdir /etc/openldap/cacerts

nss_initgroups_ignoreusers root,ldap,named,\

avahi,haldaemon,dbus,radvd,tomcat,radiusd,\

news,mailman,nscd,gdm,polkituser

nss_base_password ou=people,?sub

nss_base_shadow ou=people,?sub

nss_base_group ou=groups,?sub?&(objectCategory=group)(gidnumber=*)

nss_map_objectclass posixAccount User

nss_map_objectclass shadowAccount User

nss_map_attribute uid sAMAccountName

nss_map_attribute homeDirectory unixHomeDirectory

nss_map_attribute shadowLastChange pwdLastSet

nss_map_objectclass posixGroup group

nss_map_attribute uniqueMember member

#debug 1

The 'nss_initgroups_ignoreusers' line is quite important -- without it, Fedora 10 will fail to boot properly into GUI mode. Note also the reference to /etc/openldap/cacerts -- this directory needs to have a copy of the root certificate for your PKI, whether it's internal or third-party.

Name Service Switch

Configuration of NSS is pretty straightforward; /etc/nsswitch.conf should have the passwd, shadow, and group lines modified:

passwd: files ldap
shadow: files ldap
group: files ldap

At this point, you should be able to list user accounts -- try 'getent passwd' and look for your Active Directory accounts at the bottom of the list; if you don't see them, then uncomment the debug directive in ldap.conf, and see if the additional info gives you any clues. 'ldapsearch -x' may also provide some clues.

Kerberos 5

Kerberos deals with realms, which are kerberos administrative regions, and domains, which are DNS domains. By convention, realms are referred to in uppercase,

/etc/krb5.conf:

[libdefaults]

default_realm = FQDN.COM

ticket_lifetime = 24h

forwardable = yes

[realms]

FQDN.COM = {

kdc = <ad server>:88

}

[domain_realm]

fqdn.com = FQDN.COM

.fqdn = FQDN.COM

[appdefaults]

pam = {

debug = false

ticket_lifetime = 36000

renew_lifetime = 36000

forwardable = true

krb4_convert = false

}

Pluggable Authentication Modules

/etc/pam.d/system-auth:

auth required pam_env.so

auth sufficient pam_unix.so nullok try_first_pass

auth requisite pam_succeed_if.so uid >= 500 quiet

auth sufficient pam_krb5.so use_first_pass

auth required pam_deny.so

account required pam_unix.so broken_shadow

account sufficient pam_localuser.so

account sufficient pam_succeed_if.so uid <>

account [default=bad success=ok user_unknown=ignore] pam_krb5.so

account required pam_permit.so

password requisite pam_cracklib.so try_first_pass retry=3

password sufficient pam_unix.so sha512 shadow \

nullok try_first_pass use_authtok

password sufficient pam_krb5.so use_authtok

password required pam_deny.so

session optional pam_keyinit.so revoke

session required pam_limits.so

session [success=1 default=ignore] pam_succeed_if.so \

service in crond quiet use_uid

session required pam_unix.so

session optional pam_krb5.so

Once all of these changes have been made, Active Directory users should be able to authenticate on the new system. Since I use auto-mounted home directories, I don't have PAM creating home directories for new users, but that's not difficult to set up; look into the mkhomedir.so module if this sounds useful in your environment.

Part 2: Windows Server 2008 Active Directory Kerberos and LDAP Integration -- Active Directory Server Setup

This is the second post in a series on AD integration; the previous post provides an overview of the series; the next post deals with configuring user account authentication on Linux

Basic Installation

For my initial Active Directory server, I chose to use 64-bit Windows Server 2008 Enterprise. The decision to use Enterprise was guided by my intention of eventually supporting an internal PKI for Windows clients, rather than for anything related to the core Active Directory functionality used in this project. As an aside, this initial domain controller which will serve as the primary DC, is a virtual machine running under VMware ESXi. After the initial install reboot, I took care of housekeeping tasks including naming the server, setting a static IP address, installing VMware tools, setting the administrator password, and configuring Windows Updates. 

Once this was done, I began the process of installing Active Directory using the dcpromo.exe command. Some of the choices I made:

• Don't use 'advanced mode' installation
  
• create a new forest
  
• set the forest functional level to 2008
  
• install DNS
  
• reboot upon completion
  

After the reboot, I also configured the server as a DHCP server for its subnet. This particular system in is a subnet that is contained to a single server room, and most of the IPs on the network are statically assigned. In environments such as this with good physical security, I like to have a small (5-10 IP) range of addresses available via DHCP to simplify the process of setting up new systems and appliances; and in this case, test lab clients. To support DNS resolution for the test client systems, I set the DHCP scope options for DNS to always request DNS records, and to request DNS updates even if clients do not ask for it; these two settings will allow me to use DHCP clients during testing. Finally to authorize the DHCP service to make DNS updates, I created a service account, opened an administrative command prompt, and ran the following command:

netsh dhcp server set dnscredentials *

the '*' indicates that I wanted to provide the password interactively -- it can be replaced by the password itself for scripted use.

Identity Management for UNIX

Once this was done I moved on with configuring the server for integration. Using the Role Services pane of Server Manager, I installed 'Identity Management for UNIX', which makes some configuration changes allowing required LDAP attributes (such as uid, home directory, etc) to be set using the standard ADUC tools; some resources I've seen on the web indicate that the Active Directory schema is RFC 2307 compliant without the 'Identity Management for UNIX' addition, but I've never tested it, and don't think it's worthwhile to experiment with unless you never plan to use the Active Directory Users and Computers tools. After installation, another reboot is required.

Anonymous Binds

The next step was to set up OUs for accounts and groups. I chose to stick with UNIX conventions and create an OU called People for user accounts, and one called Groups for groups. The purpose for creating separate groups (ie, not using the CN=Users container) was because I've found it valuable to allow anonymous binding for account information, and doing this makes it easier to restrict this access to the most restrictive settings possible.

Enabling anonymous binds requires two steps. First, open Active Directory Users and Computers, check the Advanced Features option on the View menu, right-click properties for the forest root, and select the Security tab. Add the 'ANONYMOUS LOGON' user and give it read access, then click the Advanced button, select the 'ANONYMOUS LOGON' user and choose Edit; the 'Apply To' drop-down box needs to be set to 'This object and all descendant objects'. 

Even after the ANONYMOUS LOGON account has been given access, Windows 2003 and 2008 will by policy still deny anonymous binding. Changing this setting requires the use of adsiedit.msc, which is included by default in Windows Server 2008. After launching adsiedit.msc from the Start Menu, right-click the 'ADSI Edit' icon and choose 'Connect To...' then from the 'Select a well known Naming Context' drop-down, choose Configuration.  Drill down to 'CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration' and open the properties dialog for that object. Locate the dSHeuristics attribute and note what it's set to. If it is not set -- on a freshly installed machine it shouldn't be set -- it should be the 7-digit string '0000002'. If it is already set, the last digit should be set to '2' and all others should be left alone. 

Secure Sockets Layer

Although I intend to run an internal PKI from the Active Directory server, for now I plan to set up a commercial third-party SSL certificate to secure LDAP. So far I've identified this as a potential problem down the road -- Microsoft does not specify any way to choose which of multiple certificates a server will use for LDAPS, so once I add the PKI I'm not sure that LDAPS will continue to use the third-party certificate -- if this turns out to be the case, in production I'll have to create the internal CA at this point and make it's root certificate available to clients, rather than downloading the commercial CA root certificate. 

But for now, installing the third-party certificate can be done using the Certificates MMC snap-in. Open mmc.exe and add Certificates; choose 'Computer Account', then 'Local Computer' and click Finish. Expand the 'Certificates (Local Computer)' tree, right-click on Personal, and choose 'All Tasks'->'Import...'. Walk through the wizard to implement your certificate (you'll need it in a PKCS#12 format). After the certificate has been imported, it will be visible under the Personal certificates pane. Rebooting the server is all that is needed to enable LDAPS. 

Users and Groups

At this point the domain controller is pretty much all set up for basic authentication. The next step is to populate at least a minimum set of user and group accounts. The user accounts should be normal users created in the OU=People, and the groups should be global security groups created in OU=Groups. Note that due to Active Directory naming restrictions, this won't allow you to use the RedHat user-group convention, in which each user's primary group is the same as the user's name, and any additional memberships are secondary. Since this model isn't used in my environment it barely has any impact on my setup, but if you're used to using this group model, you'll need to plan around this. After creating a new user or group, open the properties dialog for the object, select the UNIX Attributes tab, select the "NIS domain" corresponding to your domain name, and set the required attributes for the object. 

Conclusion

That's pretty much it as far as Active Directory configuration goes. I anticipate adding a section on setting up Kerberos service and host principals once I get NFS working, but next up will be the scoop on configuring Linux clients to allow user authentication. 

Part 1: Windows Server 2008 Active Directory Kerberos and LDAP Integration -- Preface

This is the first post in a series on AD integration; the next post covers installing and configuring Active Directory

Systems administrators who work in heterogeneous environments understand both the value and the challenges of integrating user account information for the variety of platforms that they manage into a single system. My goal is to provide a series of technical notes detailing the processes I'm using to provide a single identity management system based on Active Directory that supports authentication for Linux, Solaris, and Mac systems -- in addition to Windows clients, of course. I'm hoping also to provide information on our use of CIFS and NFS to provide home directories to all of these platforms as well.

To start out with a bit of background, my employer has been maintaining dual account systems for many years for Solaris and Windows clients. Initially we used separate NIS and Active Directory accounts, both accounts had to be set up separately, and users were responsible for remembering both passwords, or for manually synchronizing them if desired. Shortly after I was hired, a coworker and myself were asked to look into tying together these two systems. At the time, Sun had just released version 1.0 of their Identity Synchronization product, which tied together Active Directory with Sun Directory Server. After a lot of communication with Sun's engineers we were able to put together a system that allowed us to create accounts in LDAP, and have them automatically populated to Active Directory, and to have password changes populate immediately in either direction. This solved most of our problems, most importantly simplifying our users' situation -- from their perspective, there was only one account that they had to deal with. This system matured over the years, going through various upgrades of the products involved, and expanding to support Linux systems.

Behind the scenes, however, there were still two account systems. The illusion of a single account would be occasionally shattered when a user's password didn't get synchronized properly; the system was pretty robust, but subtle differences in password strength and expiration policies, or unnoticed PKI issues would crop up, causing headaches for users and for me. As these problems continued to crop up at infrequent intervals, I began to do some research into what would be required to take the next step in evolving our network infrastructure, by truly consolidating to a single user directory.

I was initially encouraged by the number Google results that came up when I started looking at the problem -- dozens of HOWTOs, forum threads, and blog posting describing the process of authenticating all of the platforms I used against Active Directory. When I actually started setting up a test lab, however, reality hit me hard. As is often the case in this kind of situation, things that 'just worked' for other people 'just didn't' for me -- I tried many different scenarios, tweaking the suggestions in HOWTO and attempting to mix in fixes from the forum posts. When I finally made some progress, I promised myself that rather than sticking to my usual documentation procedure of writing a cookbook that worked for my exact situation and limiting it to our internal documentation, I'd try to write my own heuristic HOWTO, with enough depth and detail to hopefully be useful to others who are trying to accomplish similar goals. So, my first post is going to detail the setup of the Active Directory server, then I'll talk about setting up the various clients systems. I'll consider posting some info on ancillary processes such as account provisioning, home directory management, etc.