Windows can perform "VPN Single Sign On" whereby a (pre-configured) VPN connection is initiated from the login screen using the provided user credentials and, once established, the user is authenticated against the corporate directory server.

Only after successfully completing such a login can a remote client be used.

How can the same be accomplished with OS X?

  • Which kind of directory services do you use in the corp network? AD, OpenLDAP or any other?
    – klanomath
    Jan 1, 2015 at 14:08
  • @klanomath: Open Directory. Does that make a difference?
    – eggyal
    Jan 1, 2015 at 14:09
  • i just wanted to exclude DirectAccess and now i have to remember submerged knowledge...
    – klanomath
    Jan 1, 2015 at 14:21
  • My current thinking is that I probably need a PAM module to start the VPN connection, before any attempt is made to authenticate the user in Open Directory. I would imagine such a module already exists... but where?
    – eggyal
    Jan 2, 2015 at 0:14

3 Answers 3


You could use tunnelblick, as a front end to OpenVPN. Once installed, it runs automatically when the user logs on. It can also be configured to connect automatically, in the VPN Details dialog:

VPN Details

It appears to work with OpenDirectory also, starting from version 3.1beta16 (I am currently using version 3.4.2). Taken from the release notes (What's New in Tunnelblick 3.1beta16 (Changes from 3.1beta14))

  • Fixes issues when using OpenDirectory and the user's home directory is on a non-Mac platform.

So, in short, while it doesn't provide the VPN logon at the login screen as requested, the end result is pretty much the same - you log in and have the VPN connection already running.

Hope this helps.

  • 1
    Unless I'm very much mistaken, this solution requires the user first to login successfully on the remote machine and then a VPN connection will be established? However, the whole "raison-d'être" behind single sign on was to handle scenarios where the user does not have valid credentials on the remote machine, but can instead authenticate against the corporate directory server—but only after a VPN connection is established. So I don't see how any solution that only initiates the connection after login has been authenticated can possible suffice.
    – eggyal
    Jan 8, 2015 at 23:06
  • Yes, apologies, you are quite correct. It does require a valid local logon, which is distinct from that of the corporate server. I hadn't fully understood. Jan 8, 2015 at 23:18

Little Snitch alone is adequate. Some combination of Little Snitch, or with Apple Server software will accomplish what you seek. Once set, Little Snitch will prohibit/allow outgoing connections based on a saved (password protected) configuration. Only VPN can be configured such that that user will be unable to connect except through enabled connections. The user will have to sign into the VPN server after login manually or via keychain.

global rules settings

Apple Server is also pretty versatile, and Apple Enterprise Server support is quite good, especially since it comes free with the $20 Server software.

  • I'm sorry, but this answer is terrible. Per the question title, I want to achieve SINGLE SIGN ON. Having to manually sign in to VPN is the antithesis of what I'm after. Irrespective, this solution requires the user to have an account on the computer into which they are signing in, which again is not the scenario here.
    – eggyal
    Jan 8, 2015 at 9:47

Here is an answer Apple provides: http://support.apple.com/kb/PH15510

Mavericks Server Admin: Single sign-on authentication

OS X Server uses Kerberos for single sign-on authentication, which relieves users from entering a name and password separately for every service. With single sign-on, a user always enters a name and password in the login window. Thereafter, the user does not need to enter a name and password for AFP service, Mail service, or other services that use Kerberos authentication.

To take advantage of single sign-on, users and services must be Kerberized—configured for Kerberos authentication—and use the same Kerberos KDC server.

User accounts that reside in an LDAP directory of a Mac server and have a password type of Open Directory use the server’s built-in KDC. These user accounts are configured for Kerberos and single sign-on. The server’s Kerberized services use the server’s built-in KDC and are configured for single sign-on.

This Mac server KDC can also authenticate users for services provided by other servers. Having more servers with OS X Server use the Mac server KDC requires only minimal configuration.

Kerberos authentication

Kerberos was developed at MIT to provide secure authentication and communication over open networks like the Internet. It’s named for the three-headed dog that guarded the entrance to the underworld of Greek mythology.

Kerberos provides proof of identity for two parties. It enables you to prove who you are to network services you want to use. It also proves to your applications that network services are genuine, not spoofed.

Like other authentication systems, Kerberos does not provide authorization. Each network service determines what you are permitted to do based on your proven identity.

Kerberos permits a client and a server to identify each other much more securely than typical challenge-response password authentication methods. Kerberos also provides a single sign-on environment where users authenticate only once a day, week, or other period of time, thereby easing authentication frequency.

OS X Server offers integrated Kerberos support that virtually anyone can deploy. In fact, Kerberos deployment is so automatic that users and administrators may not realize it’s deployed.

It is the default setting for user accounts in the Mac server LDAP directory. Other services provided by the LDAP directory server, such as AFP and Mail service, also use Kerberos automatically.

If your network has other servers with OS X Server, joining them to the Kerberos server is easy, and most of their services use Kerberos automatically.

Alternatively, if your network has a Kerberos system such as Microsoft Active Directory, you can set up your Mac server and Mac computers to use it for authentication.

The Internet is inherently insecure, yet few authentication protocols provide real security. Malicious hackers can use readily available software tools to intercept passwords being sent over a network.

Many applications send passwords unencrypted, and these are ready to use as soon as they’re intercepted. Even encrypted passwords are not completely safe. Given enough time and computing power, encrypted passwords can be cracked.

To isolate passwords on your private network you can use a firewall, but this does not solve all problems. For example, a firewall does not provide security against disgruntled or malicious insiders.

Kerberos was designed to solve network security problems. It never transmits the user’s password across the network, nor does it save the password in the user’s computer memory or on disk. Therefore, even if the Kerberos credentials are cracked or compromised, the attacker does not learn the original password, so he or she can potentially compromise only a small portion of the network.

In addition to superior password management, Kerberos is also mutually authenticated. The client authenticates to the service, and the service authenticates to the client. A man-in-the-middle or spoofing attack is impossible when you are using Kerberized services, and that means users can trust the services they are accessing.

Kerberos is available on every major platform, including OS X, Windows, Linux, and other UNIX variants.

Move beyond passwords

Network authentication is difficult: to deploy a network authentication method, the client and server must agree on the authentication method. Although it is possible for client/server processes to agree on a custom authentication method, getting pervasive adoption across a suite of network protocols, platforms, and clients is virtually impossible.

For example, suppose you want to deploy smart cards as a network authentication method. Without Kerberos, you must change every client/server protocol to support the new method. The list of protocols includes SMTP, POP, IMAP, AFP, SMB, HTTP, FTP, IPP, SSH, QuickTime Streaming, DNS, LDAP, local directory domain, RPC, NFS, AFS, WebDAV, and LPR, and goes on and on.

Considering all the software that does network authentication, deploying a new authentication method across the entire suite of network protocols would be a daunting task. Although this might be feasible for software from one vendor, you’d be unlikely to get all vendors to change their client software to use your new method. Further, you’d probably also want your authentication to work on multiple platforms (such as OS X, Windows, and UNIX).

Due to the design of Kerberos, a client/server binary protocol that supports Kerberos doesn’t even know how the user proves identity. Therefore you only need to change the Kerberos client and the Kerberos server to accept a new proof of identity such as a smart card. As a result, your entire Kerberos network has now adopted the new proof-of-identity method, without deploying new versions of client and server software.

Kerberos provides a central authentication authority for the network. All Kerberos-enabled services and clients use this central authority. Administrators can centrally audit and control authentication policies and operations.

Kerberos can authenticate users for the following services of a Mac server:

  1. Login window
  2. Mail service
  3. AFP file service
  4. FTP file service
  5. SMB file service (as a member of an Active Directory Kerberos realm)
  6. VPN service
  7. Apache web service
  8. LDAP directory service
  9. Messages service
  10. NFS file service

These services have been Kerberized whether they are running or not. Only services that are Kerberized can use Kerberos to authenticate a user. OS X Server includes command-line tools for Kerberizing other services that are compatible with MIT-based Kerberos.

Single sign-on experience

Kerberos is a credential or ticket-based system. The user logs in once to the Kerberos system and is issued a ticket with a life span. During the life span of this ticket the user doesn’t need to authenticate again to access a Kerberized service.

The user’s Kerberized client software, such as the Mail application, presents a valid Kerberos ticket to authenticate the user for a Kerberized service. This provides a single sign-on experience.

A Kerberos ticket is like a press pass to a jazz festival held at multiple nightclubs over a three-day weekend. You prove your identity once to get the pass. Until the pass expires, you can show it at any nightclub to get a ticket for a performance. All participating nightclubs accept your pass without seeing your proof of identity again.

  • I really don't see how Kerberos answers this question, at all.
    – eggyal
    Jan 8, 2015 at 23:09

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .