Managing Certificates on Mac OS X


Mac OS X and Mac OS X Server have built-in support for public key certificates, referred to as simply "certificates."

More Info

Apple documentation for certificates is published as an appendix to the "Mail Service Administration" document available at www.apple.com/server/documentation.


This system relies on trusting one or more CAs, such as VeriSign. CAs sign other certificates, vouching for the identity of the certificate holders. Apple distributes the OS with a list of CAs (in /System/Library/Keychains/X509Anchors), which Apple asserts you should trust. In the following illustration, the Keychain Access application displays the partial contents of the X509Anchors keychain. The bottom of the window indicates "98 items," indicating that there are 98 CAs in this X509Anchors keychain preloaded by Apple.

Any application using the Mac OS X certificate infrastructure will automatically trust and use a certificate if it is issued or signed by a CA in X509Anchors. Likewise, the application should notify the user if the application encounters a certificate that is not issued or signed by a trusted CA.

Different applications have various ways of signaling that a certificate is in use. Safari will display a lock in the upper-right corner of the browser window. Mail will indicate if a message is signed or encrypted with a small icon and text right in the message header.

To view a secure website certificate from within Safari, click the lock in the upper-right corner of the Safari window.

According the to the following figure, the certificate for the Apple training site (https://train.apple.com) is issued by the VeriSign CA.

Even though Mail uses certificates for signing and encrypting messages, you cannot directly examine the certificate from within Mail. When Mail processes a message signed or encrypted with a certificate, Mail automatically imports the certificate into the default keychain, as well as the intermediate issuing CA if necessary.

You can view a certificate used for email with Keychain Access. In the following figure, the top part of the window shows that the certificate for ldennison@apple.com was issued by the Thawte Personal Freemail Issuing CA.

Tip

New to Keychain Access in Tiger is the search feature; you can enter an email address in the search field to highlight its certificate. This search is case-sensitive, which matters if you're searching for something with capital letters like "VeriSign" or "Thawte." You can get a free email certificate at www.thawte.com/email/index.html.


Remember, it is up to the application to notify the user if it encounters a certificate that is not signed by a trusted CA. You may run into self-signed certificates like the one shown in the following figure. You have the option to go ahead and trust the certificate anyway, or to stop browsing that site. The default in this dialog is Continue, and unfortunately, some users just go with whatever the default is whenever a window pops up. Train your users to not exchange sensitive information, such as credit card information, with a site that does not have a trusted certificate.

If you are using internal sites with certificates signed by an internal CA, prevent the verification hassle by importing the internal CA certificate into the X509Anchors keychain.

One way to import a certificate is to double-click the certificate file. Keychain Access will launch and ask if you want to import the certificate into a keychain. Be sure to select the X509Anchors keychain. Because this affects all users on a computer, you will be challenged to authenticate as an administrator before the item will be added to X509Anchors.

Using Certificates to Offer Secure Services

If you want to use SSL to protect the services you offer, you first need a certificate for each service. To obtain a certificate, you have some flexibility:

  • You can pay a trusted CA that is already in your X509Anchors keychain to sign a certificate for you.

  • You can create your own self-signed CA, distribute the self-signed CA certificate to your organization's computers, and sign certificates with your self-signed CA.

  • Although it is technically feasible to get a trusted CA to sign your CA, to sign certificates with your CA, and have those certificates trusted around the world, this is prohibitively expensive and cumbersome for most organizations.

Although the command-line openssl tools are still available to create CAs, certificates, and certificate requests, Mac OS X Server comes with several GUI tools to help you manage certificates.

With Certificate Assistant, you can:

  • Create a self-signed certificate

  • Create a certificate to be signed by your self-signed CA

  • Create a self-signed CA

  • Create a CA to be signed by your self-signed CA

  • Use your CA to create a certificate

  • Request a certificate from an existing CA (generate a certificate signing request [CSR])

  • View and evaluate certificates (similar to what you can do with Keychain Access, but you can also use this interface to ask remote hosts for their certificates to evaluate them)

Note

Apple documentation claims that Certificate Assistant resides in /Applications/Utilities, but it is actually in /System/Library/CoreServices.


Apple documentation refers to Server Admin's Certificate Manager. To get to the Certificate Manager, open Server Admin, select the computer (as opposed to any of its services), click the Settings button, then click the Certificates button. This interface displays a list of certificates in /etc/certificates. From this interface, you can:

  • Generate a self-signed certificate

  • Generate a CSR and send it via the Mail program to a CA

  • Add a signed certificate from a CA

  • Import a certificate (if you can have the certificate), the private key, the CA certificate, and optional private key passphrase.

Note

Each fresh installation of Mac OS X Server will come with a default certificate, which is used to enable SSL communications for tools such as Server Admin. This certificate, the private key, and the public key are all in the System keychain. Do not use the default certificate for services like Web services, because it is just a self-signed certificate, and your users should be trained to not trust self-signed certificates.


Although you can ask outsiders to download and trust your self-signed CA, they really have no assurance that you are who you say you are and that your CA is trustworthy.

Getting a CA to Sign Your Certificate

There are a number of certificate authorities that you can work with to get your CA on the "chain of authorities" so that when users access your site, they are not warned that OS X cannot verify your certificate. The largest of these is VeriSign, at www.verisign.com. Services such as VeriSign will work with you to get your CA added to the various chains of authorities that Web browsers use by default, although not for free, and the cost is based on your needs.

Strong Authentication

To help overcome some of the weaknesses of authenticating with only a user name and password, Mac OS X and Mac OS X Server support strong multifactor authentication.

Typical sources of multifactor authentication are the following:

  • What you know: These are things like passwords, passphrases, PINs, and so on. Your ATM PIN is an example of this.

  • What you have: The authenticator device itself. This can be anything from a USB dongle, to a keychain fob that creates passkeys for you automatically, to a card, like your ATM card.

  • Who you are: This is a physical characteristic, such as your facial structure, a fingerprint, the physical characteristics of your retina, and so on.

Mac OS X also ships with support for smart cards you can use to make your login more secure. With a smart card, you need the physical card and a password or PIN to log into your Mac. There are many different types and manufacturers of smart cards, including:

  • Chip card interface devices

  • USB readers: Athena, CRYPTOCard, GemPlus, SCM

  • PC card readers: CRYPTOCard, SCM, OmniKey

  • USB dongle readers: OmniKey

  • Smart cards (lots of different kinds):

    • CACU.S. federal government

    • BELPICBelgian personal ID card

    • JPKIJapanese ID card

  • Bind to user account

Biometrics are automated methods of recognizing a person based on a physiological or behavioral characteristic, such as the following:

  • Face, iris, retina

  • Fingerprint, hand geometry, vein pattern

  • Handwriting, voice, or typing

With biometrics, you have no password to lose or forgetyou have a single sign-on without need for Kerberos or PKI infrastructure, and they are difficult to duplicate.

The challenges, however, are that they're not yet widely implemented, people have been able to duplicate supposedly unique features, and they have a relatively high cost.

Open Directory Security

In the first part of this lesson, you learned about the password methods and hash files for local users. Now you'll examine the situation after you promote a server to be an Open Directory master and the LDAP, Password Server, and Kerberos services are all running. This section examines Password Server security before moving on to the new Directory ACLs.

Password Server

As noted before, the Password Server in Mac OS X Server supports a larger group of authentication methods than Mac OS X client does. The following tables note these:

Hashes, Authentication Methods, and Services for Local Node and ShadowHash

Hash Name

Hash Type

SASL Method

Service

CRAM-MD5

MD5

CRAM-MD5

IMAP, SMTP, LDAP, iChat

RECOVERABLE

AES with fixed key

 

APOP, WEBDAV- DIGESTPOP, Web

SALTED-SHA1

SHA1

DIGEST-MD5

loginwindow

SHA1

SHA1

DIGEST-MD5

loginwindow (deprecated)

SMB-LAN-MANAGER

LM

SMB-LAN-MANAGER

Windows95

SMB-NT

NT

SMB-NT, MS-CHAPv2, NTLMv2

VPN, All other Windows clients


Hashes, Authentication Methods, and Services for Password Server

SASL Method

Hash Stored

Service

SMB-NTLMv2

NT

Windows 2000, XP, 2003

SMB-NT

NT

Windows 98, 2000, NT, ME

SMB-LAN-MANAGER

LM

Windows 95

MS-CHAPv2

NT

VPN

OTP

None

Not used

NTLM

None

Not used

GSSAPI

None

Not used

DIGEST-MD5

MD5 with digest encoding

Login window

CRAM-MD5

MD5 with CRAM encoding

IMAP, SMTP, LDAP, iChat

WEBDAV-DIGEST

Obfuscated plaintext

Web

DHX

CRAM-MD5

Apple change password/administration tools

APOP

Obfuscated plaintext

POP


Authentication Methods Available with Password Server

Method

Used For

SMB-NTLMv2

Windows 2000, XP, and 2003 clients

SMB-NT

 

SMB-LAN-MANAGER

Windows 95, 98, and ME

MS-CHAPv2

VPN

OTP

One-time password, not really used

NTLM

NTLMv1 for pre NTSP4

GSSAPI

Kerberos

DIGEST-MD5

 

CRAM-MD5

 

WEBDAV-DIGEST

 

DHX

Used to generate a symmetric key for exchanging private Information

APOP

Authenticated POP


The Password Server is turned on only after you configure a server to be an Open Directory master.

When you create network users in the Open Directory domain, those users will have the password type of Open Directory. When you inspect the user record, this user should have two values for the AuthenticationAuthority attribute: one for Password Server, and one for Kerberos.

In the following figure, the Workgroup Manager inspector is used to examine the AuthenticationAuthority attribute of a network user (in the shared domain), and there are two values. One starts with ;ApplePasswordServer;, and the other starts with ;Kerberosv5;.

Here is what Workgroup Manager has in the Advanced sheet for an Open Directory network user.

Note

The Password Server and Kerberos services do not have a GUI tool; for the most part, they just work. /Library/Logs/slapconfig.log is a good place to look if you run into problems when you promote a server to become an Open Directory master. The mkpassdb and kadmin.local commands are not designed to be used on a daily basis, but can be useful for troubleshooting. Before trying them out for the first time on a production system, practice using these tools on a test system. sudo mkpassdb dump will display each Password Server slot with its corresponding Password ID and short name. With the kadmin.local command, you can examine and manipulate Kerberos principals, policies (which are not normally used), keytabs, and privileges. These tools are not normally used directly.


New in Mac OS X v10.4 is LDAP trusted binding, in which the client authenticates itself to the server, and the server authenticates itself to the client. Trusted binding does not by itself provide encryptionsimply mutual authentication. This is critical to prevent a client from authenticating and binding to a rogue directory server that happens to have the same name as the proper one.

Setting up a trusted bind from the client is fairly straightforward: Open Directory Access, configure LDAPv3, click the New button, and enter the server name. (It is best practice to use the FQDN, not the IP address.)

After you click Continue, Directory Access will attempt to discover information about that LDAP server. If the discovery is successful, the dialog box will change, and you can set up trusted binding. To continue with setting up trusted binding, you must specify the computer name of the client (which should be auto-populated) and an LDAP domain administrator and password.

After you successfully configure trusted binding, the client computer now has a Kerberos principal, a Password Server entry, and a computer record in Open Directory's LDAP database. The computer record has two AuthenticationAuthority values, for the Kerberos and Password Server services. This allows the client and the Open Directory master or replica to mutually authenticate each other. You cannot use DHCP-supplied LDAP server information when you implement trusted binding.

Note

Because there are now entries for this client, if you need to change the computer name, or replace the client, you may need to manually remove the entries from LDAP in order to bind another client with that computer name. It is best practice to use Directory Access to unbind a client computer before removing it from service. In Directory Access, configure LDAPv3, select the configuration for the LDAP server, and click Delete. You will be prompted to unbind with a domain administrator user name and password.


Trusted binding is available only to Mac OS X 10.4 clients and Mac OS X 10.4 servers. In fact, the binding options in Server Admin are advisory only to the directory services of other Tiger clients. The "Require clients to bind to directory" option will not disallow access by clients who have not bound. It does not affect Panther clients, Windows clients, or command-line or third-party LDAP search tools. It does not prevent a Tiger client from manually specifying an LDAP connection. You would set this option to help ensure that client computers are bound correctly, not only to ensure a good user experience, but also to add a degree of security because client and server will mutually authenticate each other.

Note

If a client is not running Mac OS X 10.4, these options are essentially ignored; all the Security checkboxes and those for requiring trusted binding are advisory only to directory services of Tiger clients.


Here are the Open Directory > Policy > Binding options in Server Admin. Note that the checkbox to "Require clients to bind to directory" is selected.

Once that option is enabled, a Tiger client using Directory Access to set up a new LDAP server hosted by a Tiger Open Directory master will be prompted to supply a directory administrator user name and password. Notice that the Manual button is dimmed (but the Cancel button is not).

After successfully authenticating, the computer will now bind to the directory using the distinguished name of the computer record that was created in the LDAP directory during the process of setting up the trusted bind. Note that all of the Security Policy options are left unselected by default. These options are useful only if the server supports them.

Keeping Your Backed-Up Information Secure

Mac OS X Tiger makes it easy to back up your Open Directory master with Server Admin. You specify the location, and Server Admin creates a disk image with all the files necessary to back up your Open Directory master information.

It is best practice to specify a password for the archive to keep it secret.

This archive contains hashes of passwords from the Password Server and Kerberos, and it contains the hashed password of the rootdn for the LDAP database (in slapd_macosxserver.conf). Treat these files with care. Multiple backups of these files are probably a good idea.

Prevent Anonymous Access to Your Directory

By default, the LDAP server will answer all queries it sees. This can be a security concern in some environments; In general, you might not want to allow everyone to harvest information from your shared domain. Although neither passwords nor even hashes of passwords are stored in the LDAP directory, other information is there, such as short names, group membership, and possibly email addresses. Furthermore, new to Tiger is the ability to use Workgroup Manager to store information such as phone number and addressinformation that can be used for social engineering.

In previous versions of Mac OS X Server, one way to increase directory security was to add the line disallow bind_anon to /etc/openldap/slapd.conf, use Directory Access at the client to specify a user name for LDAP requests, and enable LDAP over SSL. The disallow bind_anon line is not recommended for use with Mac OS X Server 10.4, because trusted binding requires an initial anonymous access to the LDAP directory. Though it is not supported in the GUI, a better approach is to implement directory access control lists (DACLs).

DACLs are a new feature in Tiger server. The implementation of DACLs introduces the ability to store ACLs right in the LDAP directory itself. One big advantage of this method is that the ACLs can easily be replicated to Open Directory replicas; previously, you would have had to edit config files at each server if you wanted to make any change in access. Another advantage is that since the information is in the LDAP directory, it's easy to export and import DACLs via LDIF files.

More Info

For more info on access control lists with OpenLDAP, see www.openldap.org/doc/admin22/slapdconfig.html#Access%20Control.


Note

Tiger's implementation of OpenLDAP is 2.2; make sure you consult the correct documentation.


This section of /etc/openldap/slapd_macosxserver.conf points to the location of the default DACL:

# This file should NOT be world readable. # This file is maintained by Server Admin. # # Access Controls access specified-in-directory apple-acl "cn=default,cn=accesscontrols,dc=mainserver, dc=pretendco,dc=com"


Note

Though we can't show it properly on the printed page, you should type the last part of the previous command as one line without a paragraph break.


Here is an Inspector view in Workgroup Manager of the default DACL. The AcessControlEntry attribute in this example has four entries. Each entry consists of a number, a colon, and the rule itself. This example controls access to userPassword, apple-user-authenticationhint, apple-user-picture, and * for everything else not specified.

In order to better view an attribute's entry, you can highlight that entry and click the Edit button.

Here are the general steps to disable anonymous binding and queries to your LDAP server, yet allow enough access for regular operation:

1.

Use Workgroup Manager to update the config > default > AccessControlEntry entries.

2.

On the Open Directory master, use Directory Access to specify "Use authentication when connecting."

3.

Make sure that all replicas and clients are using trusted binding or specify "Use authentication when connecting."

To disable most anonymous queries to the LDAP database, here are some suggested AccessControlEntry values to add to enable anonymous access where necessary:

Note

Again, for each command shown here, type one line of text without paragraph breaks.


[View full width]

1300:access to dn.base="" by * read 1310:access to dn.subtree="cn=config,dc=diradmin,dc=mainserver,dc=pretendco,dc=com" by sockurl="ldapi://%2Fvar%2Frun%2Fldapi" write by group/posixGroup/memberU write by * read 1320:access to dn.subtree="uid=diradmin,cn=users,dc=diradmin,dc=mainserver,dc=pretendco, dc=com" by sockurl="ldapi://%2Fvar%2Frun%2Fldapi" write by group/posixGroup/memberUid= "cn=admin,cn=groups,dc=mainserver,dc=pretendco,dc=com" write by * read 1330:access to attr=authAuthority by self write by sockurl="ldapi://%2Fvar%2Frun%2Fldapi" write by group/posixGroup/memberU write by users read by anonymous 1999:access to * by sockurl="ldapi://%2Fvar%2Frun%2Fldapi" write by group/posixGroup/ memberU write by users read by anonymous auth


After you update an AccessControlEntry, the LDAP server will automatically use the new settings.

To test whether or not your updated DACLs prevent anonymous access to your LDAP Directory, use ldapsearch with the x flag:

ldapsearch -x -h mainserver.pretendco.com -b cn=users,dc=www,dc=ssh22,dc=com uid=diradmin


Update Directory Access on the Open Directory Master

The Open Directory master must be updated to no longer access itself anonymously:

1.

Open Directory Access.

2.

Configure LDAPv3.

3.

Highlight the entry for the server, and click Edit.

As you can see, the server will try to anonymously authenticate to itself.

4.

Click the Security button, and enter a name and password for authenticating.

Note

The distinguished name should be in the form of uid=diradmin,cn=users,dc=mainserver,dc=pretendco,dc=com.





Apple Training Series. Mac OS X System Administration Reference, Volume 1
Apple Training Series: Mac OS X System Administration Reference, Volume 1
ISBN: 032136984X
EAN: 2147483647
Year: 2005
Pages: 258
Authors: Schoun Regan

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net