This discussion is archived
5088 Views 8 Replies Latest reply: Jun 8, 2008 9:11 PM by rkovelman
Currently Being ModeratedJun 3, 2008 7:14 AM (in response to Peter Glock)I would make sure under authentication you select Kerberos, kill users after they have been idle, make sure you have a valid cert, disable guest access.
For SSL go here:
Below is what that link states
The difference between 10.4 and 10.5 lies entirely in /etc/openldap/ldap.conf. Where before it used to say
TLS_REQCERT = never
now it says
TLS_REQCERT = demand
This change means that the underlying ldap client will only use SSL certificates that it thinks are valid dropping the connection attempt if it thinks the cert is bad. So, what constiutes a valid cert?
Out of the box... nothing. The LDAP client trusts no one. Even if you actually paid for your SSL certificate and you have no issues when you use it to secure a website, the LDAP client will still refuse it. Annoyingly the GUI, in this case Directory Utility, will happily show you a green dot next to your server, it's just that it won't actually be used. If you require binding and SSL, that should fail as well.
While this is annoying if you didn't expect it, I find it hard to argue that it was a bad move. Without validating a site against its own certificate left the client systems open to something as simple as a DNS poisoning attack. So I do feel that this is a good thing, but it cetainly does take a bit more work to get things functioning.
Test via the CLI
The easiest way to test what exactly is going on is to use the ldapsearch command to verify if you're able to connect or not. This assumes that you've first set up OD and enabled SSL for LDAP, either using the default certificate on the server or one you've configured yourself.
ldapsearch -v -x -H ldaps://biggie.afp548.com -b "dc=biggie,dc=afp548,dc=com"
Substituting in your correct server FQDN and search domain. This should fail on a stock 10.5 install with this error.
ldap_bind: Can't contact LDAP server (-1)
additional info: error:14090086:SSL routines:SSL3GET_SERVERCERTIFICATE:certificate verify failed
Fairly self-explanatory, at least to what the error is. So now how to fix it.
Get the Cert
You're going to need to feed the cert to the LDAP client so that it knows to trust it. While it's possible to do this via exporting the cert from the server itself it's typically easier to use the "openssl s_client" to snarf the cert.
openssl s_client -connect biggie.afp548.com:636
Which should come back with a deluge of information for you. Within that is going to be a dozen or more lines that are blocked off by:
Take that text, including the begin certificate and end certificate lines and paste them into a text file. A CLI text editor would be best for this to ensure that you don't accidentally save it as a .rtf or something funky like that.
For purposes of demonstration we'll assume that you've saved the cert to /tmp/ssl.cert.
Note: you should get an error number 18 or 19 when using the s_client. This refers to either a self-signed certificate, 18, or a self-signed certificate in the chain, 19. Keep this in mind as the next step should clear this out.
BTW, control-c to get out of the s_client connection.
Test the Cert
Now that you have the cert sequestered into a text file you can test again with s_client manually specifying the certificate.
openssl s_client -connect biggie.afp548.com:636 -CAfile /tmp/ssl.cert
Which should display similar output to before, however, with a significant change to the last line:
Verify return code: 0 (ok)
Instead of either the 18 or 19 that you were getting before. This means that you've successfully managed to get openssl to be happy with the certificate that you're using on the remote server. So now to make LDAP as happy...
You are going to need to add a new line to /etc/openldap/ldap.conf that points to the certificate you've just pulled down. I tend to keep things tidy here and create a /etc/openldap/certs folder and then just copy the text file that we got before into there. Here we'll assume you renamed the file the name of the server and put it into this location.
After moving the cert you can add one line into /etc/openldap/ldap.conf
Now retest with the ldapsearch command and see if it works.
ldapsearch -v -x -H ldaps://biggie.afp548.com -b "dc=biggie,dc=afp548,dc=com"
Should actually return an LDIF of your whole LDAP setup, so this may take a while. Trim down the search if you want.
Ensuring OD Works
At this point you should be able to join and use an SSL-secured OD setup via Directory Utility. So please do that at this time. You may need to kick Directory Services if you had already attempted to setup the LDAP server.
sudo killall DirectoryService
Securing a Collection of Certs
The method above will only allow that one specific server, with that one specific cert to be trusted. If you have multiple LDAP servers you're working with you're going to need to specify those individually, or put them all in the same directory and point ldap.conf towards them. Here's how to do the later.
Grab all of the certs as before using openssl s_client.
Now you're going to have to use another OpenSSL utility to get the certs into a hashed format.For each cert you will run the it through c_hash which will give you a name that you'll need to rename the cert file to.
03be8eb2.0 => /etc/openldap/certs/biggie.afp548.com
In this example you'd rename your existing cert file to 03be8eb2.0
Then you can add
to your /etc/openldap/ldap.conf file.
Probably best to remove any earlier TLS_CACERT directives you have in ldap.conf at this time as well.
On the Other Hand
You could revert the ldap.conf file back to the 10.4 behavior and be done with all this...
Note that while it would certainly make most of the pain go away, OpenSSL and therefor the LDAP libraries have no concept of what a keychain is. So, no, importing the certs into your keychain won't do anything for the LDAP issue.
You will never be able to use the default certificate that comes with OS X Server without changing TLS_REQCERT back to never. The default certificate isn't configured with a hostname so it will never pass an integrity check.
As mentioned by Mr. McCune in the comments, you may also want to investigate pointing ldap.conf to the default trusted root store that is included with curl on OS X.
Which should allow you to use a purchased certificate without having to do additionaly mods to ldap.conf.ACTC, ACHD, ACDT, ACPT, Mac OS X (10.4.11)
Currently Being ModeratedJun 6, 2008 3:44 AM (in response to rkovelman)Thanks for the link I'm also a regular visitor to afp548.com so had come across this article already.
However, this only provides advice about securing the authentication of afp sessions, not the content of any documents that pass over the wire. If you use wireshark or ettercap you will be able to see that the authentication is encrypted, but data transfer is not.
So, the question remains - any way of securing afp sessions without vpn or ssh/ssl tunneling?Power Mac g5, MacBook Pro, 2 x iMac g5, g4 Quicksilver, mac mini, iBook G4..., Mac OS X (10.5.3), Infrant readyNAS 600 (2TB)
Currently Being ModeratedJun 6, 2008 7:09 AM (in response to Peter Glock)Well even a VPN connection is unsecure unless the server is plugged directly in to the VPN Appliance. Otherwise the traffic is still open. The only thing secure is the VPN connection from the mobile user to the VPN appliance. What I would suggest is doing SSL or SSH. Are you trying make certification or compliance? Just curious for why you need such a secure network...ACTC, ACHD, ACDT, ACPT, Mac OS X (10.4.11)
Currently Being ModeratedJun 6, 2008 11:00 AM (in response to rkovelman)I'm following the recommendations of the Jericho Forum (see http://www.opengroup.org/jericho/ ).
I support a number of mobile users, most of whom are decidedly non-technical. I'm trying to provide all services in a secure way irrespective of whether they are in the office, at home or somewhere else so that they don't have to change behaviour. I've set all email settings to use secure IMAP and LDAP/OD settings to use SSL, now I'd like to do the same for AFP.
Any help appreciated.Power Mac g5, MacBook Pro, 2 x iMac g5, g4 Quicksilver, mac mini, iBook G4..., Mac OS X (10.5.3), Infrant readyNAS 600 (2TB)
Currently Being ModeratedJun 6, 2008 11:53 AM (in response to Peter Glock)Well, you might go with an ssl-based VPN such as http://www.sshtools.com/showSslExplorer.do
or use a dedicated hardware appliance such as the Zyxel SSL10
(SSL VPN functionality also in the higher-end Zywall 70 with IDP
I gave the URL for their UK pages (they have US pages as well, possibly others...)
Or of course, another vendor if you prefer.
Currently Being ModeratedJun 6, 2008 2:35 PM (in response to davidh)Thanks for the suggestion. I have been using sslexplorer for several years to give me remote access for admin purposes, I find it very good when tunneling through the various firewalls I find myself behind
I'm obviously not stating the requirement clearly enough. I want to have a base set of services for mobile users so that they do not have to change anything between working in the office and remotely.
I have this working for mail, address book and calendars and now want to set up secure access for fileshares and PHDs (for online backup)
I'm currently using webdav over ssl for giving remote access to shared files, but this causes problems with file permissions (_www is the user for all files created on the server, I would like more granular access), opening/saving files in MS Office and no access to PHDs.
I could tunnel afp (or maybe smb) over ssh or establish IPSec, PPTP or ssl VPN but this would involve the user understanding that they were 'out of the office' and doing something different.
AFP over ssh was working in 10.4 server, can I get the same from 10.5?Power Mac g5, MacBook Pro, 2 x iMac g5, g4 Quicksilver, mac mini, iBook G4..., Mac OS X (10.5.3), Infrant readyNAS 600 (2TB)
Currently Being ModeratedJun 8, 2008 9:11 PM (in response to Peter Glock)I understand what your trying to accomplish but remember that any traffic before the VPN is not encrypted so as of right now your not secure in any way. Going beyond that depending on the VPN connection the data wont be plain text BUT might be easy to grab.
Have you called Apple and asked about what your trying to do? There is an old Unix way I did it with NetaTalk found here:
With this you can enable SSL over AFP.ACTC, ACHD, ACDT, ACPT, Mac OS X (10.4.11)