The weblog of an IT pro specializing in virtualization, storage, and servers
You are currently browsing articles tagged Apache.
In case you’ve been hiding under a rock and haven’t yet heard (is that possible?), Apple today announced the iPhone:
GSM/EDGE, Wi-Fi, and Bluetooth…runs an embedded form of OS X…super-slick user interface…it’s enough to make a gadget geek like me salivate.
If the iPhone works half as well as claimed, it will be a tremendous device. If it works as well as claimed, it will be a revolutionary device.
So, yes, I don’t technically need one…but I sure would like to have one.
I’ll break the information down according by the article to which the information pertains. If the information pertains to all the articles equally, it is included in the “All Articles†portion. Links back to the original articles are included.
One thing in common across all these articles is the need to create special accounts in Active Directory. I originally recommended the use of computer accounts, but over the course of time additional integration tasks with Kerberos have led me to believe that the user of user accounts, not computer accounts, is the best way to handle this. In a very early Linux-AD integration article, I discussed the use of computer accounts instead of user accounts, and the use of the ktpass.exe command to extract a keytab from a computer account. At that time, it seemed reasonable to recommend computer accounts—we were only discussing a single service principal (the host itself), and using a computer account made sense.
However, because of the fact that additional accounts will have to be created for additional service principals (for example, if you are interested in using Kerberos-based SSO with Apache) and because you can’t have multiple computer accounts with the same name, it’s just as well to use a user account with a naming convention that describes the purpose of each account. For example, something like “host-fqdn†for the host/fqdn@REALM service principal (used for scenarios involving pam_krb5 and “native†Kerberos/GSSAPI authentication), and “http-fqdn†for the HTTP/fqdn@REALM service principal (used by mod_auth_kerb for Apache-Kerberos integration). This provides an easy way to distinguish between these accounts, and allows for the multiple accounts that are required in these kinds of scenarios.
Finally, the use of user accounts will eliminate some spurious error messages that ktpass.exe generates when run against a computer account. Note that these error messages are not substantive; things will still work with a computer account. It’s just that ktpass.exe appears to have been intended to run against a user account.
In addition, because of differences in the encryption types supported by Active Directory and many Unix/Linux implementations, I have found that using the “+DesOnly†switch with ktpass.exe seems to help.
An updated ktpass.exe, accounting for the change to a user account and the desire to use DES encryption types, would look something like this:
ktpass.exe -princ host/fqdn@REALM -mapuser DOMAIN\account -crypto des-cbc-md5 +DesOnly -pass Password123 -ptype KRB5_NT_PRINCIPAL -out c:\filename.keytab
Please note that this command, particularly the service principal name (as specified by the “-princ†parameter) is CASE SENSITIVE. For example, the host SPN (i.e., “host/fqdn@REALMâ€) that is used by pam_krb5 and “native†Kerberos/GSSAPI authentication is lowercase. However, the HTTP SPN (used by mod_auth_kerb with Apache) needs to be uppercase. In both cases, the Kerberos realm (which should be equivalent to the Active Directory DNS domain name) must be in uppercase.
The original article is found here.
In addition to the switch from a computer account to a user account as described above, the only real change to this article pertains to the /etc/ldap.conf file that configures the nss_ldap library. Remember that in almost all of these scenarios, we are using Kerberos for authentication and LDAP for account information, i.e., storing the information that would normally be stored in /etc/passwd.
The original article calls for /etc/ldap.conf to include this line:
nss_base_group dc=mydomain,dc=com
To help optimize LDAP traffic against Active Directory, change the /etc/ldap.conf as follows:
nss_base_group dc=mydomain,dc=com?sub? &(objectCategory=group)(gidnumber=*)
(This should all be on a single line.) This will help reduce the query load on Active Directory by limiting the types of objects for which searches will be issued; in addition, the “objectCategory†type is indexed, which also also greatly speed operations.
Speaking of indexing, if the pam_login_attribute is not modified (it defaults to uid), you’ll also need to index the uid attribute in order to avoid heavy CPU utilization and delays in responses from Active Directory. This was mentioned in the updated Linux-AD R2 instructions. Alternately, you can change the pam_login_attribute in /etc/ldap.conf to an indexed attribute, like sAMAccountName.
Last, you may find it useful to edit /etc/ldap.conf and change the gecos field mapping from name to cn (i.e., use “nss_map_attribute gecos cn†instead of “nss_map_attribute gecos nameâ€).
The latest version of these instructions are found posted here.
Again, other than the change to a user account instead of a computer account (as described above), the changes mentioned in the previous section also apply here:
Otherwise, the revised instructions are reasonably accurate and seem to work pretty well.
This article is found here, and already incorporates most of the changes mentioned in this posting. No suggested changes are needed at this time.
This article can be found posted here.
This one is a pretty recent article (published within the last week or so), and so already incorporates most of the changes suggested here. The information that I don’t have yet, however, is exactly how to incorporate some of the other suggested changes. For example, I’m not yet sure how to use the ldapclient command to modify the LDAP client profile (Solaris 10 doesn’t use nss_ldap by default) to include the refined group query. I suspect that this command would work correctly:
ldapclient mod -a serviceSearchDescriptor=group:dc=example,dc=com?sub ?&(objectCategory=group)(gidNumber=*)
Of course, the ldapclient command syntax would change depending upon if this was an initial setup or a change to an existing setup.
Likewise, I’m not sure which login attribute the Solaris LDAP libraries are looking for—uid, sAMAccountName, or something else entirely? If anyone with more Solaris 10 experience than me has the answers to these questions, I’d love to know.
As I continue to expand my knowledge of using Kerberos to integrate these various platforms and applications, I’ll post additional information here. I know that a number of you have been posting questions in the comments for these various articles; keep the questions coming. I may not know the answer right away, but I’ll sure do my best to find out!
Tags: ActiveDirectory, Apache, Interoperability, Kerberos, Microsoft, Networking, UNIX
The key to the magic here is the mod_auth_kerb module, which adds Kerberos authentication to Apache. This module not only allows Apache to use Kerberos on the “back-end,†so to speak, but also supports the SPNEGO and GSS-API stuff on the “front-end†that allow it to transparently authenticate users connecting with supported browsers, without ever prompting for a password.
These steps need to be repeated for each Apache server that will authenticating via Kerberos to Active Directory.
ktpass -princ HTTP/fqdn@REALM -mapuser DOMAIN\account -crypto DES-CBC-MD5 +DesOnly -pass password -ptype KRB5_NT_PRINCIPAL -out filename
Be sure to specify a unique output filename (so that you don’t overwrite files; each server/account will needs its own unique file). I suggest using the server’s name as the filename, i.e., something like “lnxservername.keytabâ€.
It would be ideal if we could leverage the existing computer account that may exist for that Linux server for host authentication (I’m assuming you followed my instructions for integrating host authentication into Active Directory, yes?), but for some reason it doesn’t work. We can use the SetSPN utility to add the appropriate SPN to the computer account, but authentication still doesn’t work. If any Kerberos/Active Directory gurus out there have some insight on this, please let me know. (By the way, this may be one reason for using user accounts for all the various SPNs—HOST/fqdn@REALM, HTTP/fqdn@REALM, etc.—as some of the online guides for integrating Linux and Active Directory have suggested.)
Now we’re ready to move on to configuring the Apache servers.
Repeat these steps for each Apache server. In case I haven’t already mentioned this, I’m assuming you’re running Apache 2.0 on Linux, and not on some flavor of Windows.
LoadModule auth_kerb_module modules/mod_auth_kerb.so <Location /secured> AuthType Kerberos AuthName “Kerberos Login†KrbMethodNegotiate On KrbMethodK5Passwd On KrbAuthRealms EXAMPLE.COM Krb5KeyTab /etc/httpd/conf/httpd.keytab require valid-user </Location>
Substitute the correct values for the KrbAuthRealms directive (your Kerberos realm name will be your Active Directory domain name in UPPERCASE) and the location and name of the keytab. (We’ll copy the keytab over shortly.)
Assuming that your Apache server is accessible as web.example.com, you should now be able to fire up a recent version of Internet Explorer (one that supports Integrated Windows Authentication) and navigate to the “http://web.example.com/secured†URL and gain access, without getting prompted for authentication. A quick review of the access logs (typically /var/log/httpd/access_log) shows that you are being authenticated as the user that is currently logged on to Windows. (If the browser you are using doesn’t support the transparent authentication, you’ll get prompted for a username and password, in which case you can enter your Active Directory username and password and gain access to the site.)
If this doesn’t work, go back and double-check your ktpass.exe command (noting that the case of the Kerberos principal specified by the “-princ†option is important, as it is case-sensitive). Also check the permissions on the keytab after it has been copied over to the Linux server; it must be readable by the Apache user (and should not be readable by any other users or groups). Finally, try unchecking the “Enable Integrated Windows Authentication†option in Internet Explorer, restarting IE, re-checking that box, and then restarting IE again. (Don’t ask why, but it does seem to help in some instances.)
Finally, note that a few other browsers also support the transparent authentication. I personally tested Safari and Shiira on Mac OS X, and both worked fine (after I had obtained a Kerberos ticket, either using the Kerberos application or kinit from a shell prompt). Camino didn’t work, which is a bummer. I haven’t tested Firefox yet, but I’m told that Firefox also works, although an extension may be required.
Extensive credit goes to Achim Grolms for his walk-through of using mod_auth_kerb with a Windows KDC.
Tags: ActiveDirectory, Apache, CentOS, Interoperability, Kerberos, Linux, Web
A while ago, I discussed the use of Apache to protect OWA from web-based attacks. This configuration placed an Apache HTTP server in front of a server running Microsoft Exchange Server 2003 to protect it against web-based attacks, offload SSL encryption, and enable name-based virtual hosts (for the conservation of public DNS hostnames, especially important for smaller organizations). While this is a useful configuration, it is not without its drawbacks.
First, let’s review some of the advantages of this type of configuration:
Now, for some of the disadvantages of this type of configuration:
I’m sure there are other disadvantages as well. Anyone care to comment and share their experiences?
Tags: Apache, Exchange, Interoperability, SSL
Reading about the “Vulnerability Discovery and Remediation Open Source Hardening Project‗a security audit funded by the Department of Homeland Security to regularly review popular open source software (this article has more information)—got me thinking.
The article that sparked my thinking discussed how a critical flaw had been discovered in the X Window System. This flaw was described as one of the most serious flaws uncovered to date. The flaw was corrected quickly, as is typical of most open source projects, but it wasn’t really the flaw itself or the quick response to the flaw that really got to me. Instead, it was the fact that someone was even able to search for such flaws.
The war-cry for open source proponents has always been, “Our software is more secure because more people have seen the code and reviewed it.†Until now, I wasn’t so sure about that argument; after all, how many people were like me? People who loved the projects, supported them in whatever way they could, but aren’t developers? An ordinary guy like me can’t contribute anything significant to an open source project because I don’t know C, C++, C#, Java, Objective-C, or anything else. The fact that I could review the code, until now, didn’t really do me any good. Or so I thought.
Perhaps I’m just coming late to the party. Perhaps it’s the involvement of the government, using my tax dollars, that has driven the idea home. Either way, now I see that the very right to review the source code is what makes open source projects so powerful in comparison with closed source software. As this DHS-sponsored project pores over millions of lines of code to find obscure bugs like the one described above, everyone (even Windows users) benefits. As security flaws, buffer overflows, etc., are corrected in software packages such as Apache (which runs the majority of web sites on the Internet, last I checked), FreeBSD, the Linux kernel, MySQL, the Internet and our own private networks become more secure, more protected, and less likely to be used in attacks against others. This is what the open source proponents have been so excited about, and why support for open source software is so strong.
This doesn’t mean that open source projects are automatically “more secure,†nor does it mean that we should all eschew all forms of commercial software in favor of open source equivalents. But it does mean that we do need to strongly consider open source equivalents, especially the high-profile ones, when developing solutions for customers. In my opinion, it would be a disservice otherwise.
Outlook Web Access (OWA) is the web-based interface for accessing e-mail and other resources handled by Microsoft Exchange. Unfortunately, OWA’s popularity also makes it the target of numerous worms and security exploits. As a result, many organizations seek to deploy OWA behind a reverse proxy that can help shield OWA from web-based attacks and exploits. In this posting, I’m going to share information to help build a reverse proxy using Apache 2.0.
Here’s a skeleton of an httpd.conf file to support Apache as a reverse proxy in front of OWA:
NameVirtualHost 1.2.3.4:80 NameVirtualHost 1.2.3.4:443 ProxyRequests Off <VirtualHost 1.2.3.4:443> ServerAdmin webmaster@domain.com ServerName webmail.domain.com DocumentRoot /var/www/webmail RequestHeader set Front-End-Https “On†ProxyRequests Off ProxyPreserveHost On SSLEngine On SSLCertificateFile conf/webmail-ssl-cert.pem <Location /exchange> ProxyPass http://mail.domain.com/exchange ProxyPassReverse http://mail.domain.com/exchange SSLRequireSSL </Location> <Location /exchweb> ProxyPass http://mail.domain.com/exchweb ProxyPassReverse http://mail.domain.com/exchweb SSLRequireSSL </Location> <Location /public> ProxyPass http://mail.domain.com/public ProxyPassReverse http://mail.domain.com/public SSLRequireSSL </Location> </VirtualHost>
The key portions of this configuration are described below, along with some supporting information.
With this configuration in place, the following benefits are realized:
Using Apache to serve as a reverse proxy for OWA is a cost-effective way to add another layer of security to an Exchange-based messaging infrastructure.
With the majority of my Linux servers now authenticating against Active Directory, I’m now able to broaden my integration focus and work on some related tasks:
SASL2/PAM: I still have one server, running SASL2, that has not been switched over to the standard Kerberos/LDAP configuration. I’ll need to research the interplay between SASL2 and PAM before I tackle this one.
OpenBSD Authentication: I haven’t touched any of the OpenBSD servers yet for Kerberos/LDAP authentication.
VPN Authentication via RADIUS: I’d like to use RADIUS to handle some VPN authentication against Active Directory as well. I don’t anticipate this should be too terribly difficult, but it is something that is rather new to me.
Apache Authentication via Kerberos to AD: One of the documents that helped me in getting the pam_krb5 stuff working was for using mod_auth_kerb with Apache (more information also posted here as well). I’d like to deploy this for some select areas of our intranet and extranet sites, to add an additional layer of security on top of what is already present.
Of course, this is in addition to trying to establish an internal news server running INNd (and then migrating content from Exchange Server 2003 into this news server) and working on Squid log analysis tools. I’ll probably start investigating Squid authentication options as well, since that would be very helpful to my customers (especially if I can get the authentication to be transparent, or very nearly so). On top of that I have duties in church, work as a manager overseeing employees, and things to do as a dad. Whew! I often wonder if I am just not efficient with managing my time, or if I just have too much to do.
A fair number of people have asked me why I use an Apple Mac when my business centers primarily around Microsoft products such as Windows Server 2003, Active Directory, and Exchange? That’s a reasonable question.
My computer is simply a tool to get my job done. About two years ago, I started to evaluate the tasks that I tackle on a regular basis as part of supporting my customers’ networks. In reviewing those tasks, it become evident to me that using Windows myself was not a prerequisite for designing, installing, and supporting Windows-based networks. I could run a different OS—like Linux or Mac OS X—and still be perfectly able to get my job done. In fact, given that I wanted to increase the amount of work that my company did with open source software such as Linux, Apache, Postfix, and SpamAssassin, something other than Windows might actually make that easier.
I then set out to compare the alternatives. After comparing Linux and Mac OS X, I found that Mac OS X had the best fit for my particular needs. I loved the mix of open source technologies (the BSD underpinnings and various other open source projects) and closed software (the ultrasmooth Aqua interface). I loved the hardware. And, most importantly, I found that there were applications available for Mac OS X to help me get my job done. (See my blog posting about Preferred Mac OS X Applications.) The fact that many of the applications I needed for my job were open source applications was a bonus.
Is Mac OS X right for you? I don’t know; that depends upon what you do at your job. I believe that Mac OS X is a great fit for more people than Windows, but I also believe that people must use what is most ideally suited for their work. If that is Windows; so be it. If that is Linux, then great. And if, like me, it is Mac OS X, then fantastic. Each of these operating systems have their own strengths and weaknesses, and it is up to each user to determine which OS is right for them.
Tags: Apache, Linux, Macintosh, Microsoft, Postfix, SpamAssassin
I’ve added a couple new links to my del.icio.us bookmarks. Most notably, I’ve added an entry for a recent article on ONLamp.com, a site hosted by the O’Reilly Network, on mod_security.
The article, Securing Web Services with mod_security, is a great introduction to an Apache module that I’ve known about and used for a while now. Similar to URLScan for IIS 5.0, mod_security serves to block malicious URLs and invalid requests, even within encrypted HTTPS sessions. As such, it acts as the perfect complement to firewalls and intrusion detection/prevention systems (both network-based and host-based), which typically operate at lower layers of the networking stack.
If you use Apache, I urge you to evaluate and deploy mod_security to enhance your web server’s security.
Recent Bookmarks
Scott’s Weblog by Scott Lowe is licensed under a Creative Commons Attribution-Noncommercial-No Derivative Works 3.0 United States License.
Recent Comments