From: Matthew Newton <mcn4@leicester.ac.uk>
Date: Fri, 10 Feb 2012 00:51:07 +0000 (+0000)
Subject: Add examples to EAP-TLS virtual server
X-Git-Tag: release_3_0_0_beta0~318
X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=86fe73de475bf6037cf56dfddd006b21c3295090;p=thirdparty%2Ffreeradius-server.git

Add examples to EAP-TLS virtual server
---

diff --git a/raddb/sites-available/check-eap-tls b/raddb/sites-available/check-eap-tls
index 15dc628d8fd..17fdc779ef8 100644
--- a/raddb/sites-available/check-eap-tls
+++ b/raddb/sites-available/check-eap-tls
@@ -1,6 +1,6 @@
 # This virtual server allows EAP-TLS to reject access requests
 # based on some certificate attributes.
-
+#
 # Value-pairs that are available for checking include:
 #
 #   TLS-Client-Cert-Subject
@@ -11,6 +11,14 @@
 # To see a full list of attributes, run the server in debug mode
 # with this virtual server configured, and look at the attributes
 # passed in to this virtual server.
+#
+#
+# This virtual server is also useful when using EAP-TLS as it is only called
+# once, just before the final Accept is about to be returned from eap, whereas
+# the outer authorize section is called multiple times for each challenge /
+# response. For this reason, here may be a good location to put authentication
+# logging, and modules that check for further authorization, especially if they
+# hit external services such as sql or ldap.
 
 server check-eap-tls {
 
@@ -21,31 +29,100 @@ server check-eap-tls {
 # set it to Reject.
 
 authorize {
-	if ("%{TLS-Client-Cert-Common-Name}" == "client.example.com") {
-		update config {
-			Auth-Type = Accept
-		}
-	}
-	else {
-		update config {
-			Auth-Type = Reject
-		}
-		update reply {
-			Reply-Message = "Your certificate is not valid."
-		}
+
+	#
+	# By default, we just accept the request:
+	#
+	update config {
+		Auth-Type := Accept
 	}
 
+
+	#
+	# Check the client certificate matches a string, and reject otherwise
+	#
+
+#	if ("%{TLS-Client-Cert-Common-Name}" == "client.example.com") {
+#		update config {
+#			Auth-Type := Accept
+#		}
+#	}
+#	else {
+#		update config {
+#			Auth-Type := Reject
+#		}
+#		update reply {
+#			Reply-Message := "Your certificate is not valid."
+#		}
+#	}
+
+
+	#
+	# Check the client certificate common name against the supplied User-Name
+	#
 #	if ("host/%{TLS-Client-Cert-Common-Name}" == "%{User-Name}") {
 #		update config {
-#			Auth-Type = Accept
+#			Auth-Type := Accept
 #		}
 #	}
 #	else {
 #		update config {
-#			Auth-Type = Reject
+#			Auth-Type := Reject
+#		}
+#	}
+
+
+	#
+	# This is a convenient place to call LDAP, for example, when using
+	# EAP-TLS, as it will only be called once, after all certificates as
+	# part of the EAP-TLS challenge process have been verified.
+	#
+	# An example could be to use LDAP to check that the connecting host, as
+	# well as presenting a valid certificate, is also in a group based on
+	# the User-Name (assuming this contains the service principal name).
+	# Settings such as the following could be used in the ldap module
+	# configuration:
+	#
+	# basedn = "dc=example, dc=com"
+	# filter = "(servicePrincipalName=%{User-Name})"
+	# base_filter = "(objectClass=computer)"
+	# groupname_attribute = cn
+	# groupmembership_filter = "(&(objectClass=group)(member=%{control:Ldap-UserDn}))"
+	
+#	ldap
+
+	# Now let's test membership of an LDAP group (the ldap bind user will
+	# need permission to read this group membership):
+
+#	if (!(Ldap-Group == "Permitted-Laptops")) {
+#		update config {
+#			Auth-Type := Reject
 #		}
 #	}
 
+	# or, to be more specific, you could use the group's full DN:
+	# if (!(Ldap-Group == "CN=Permitted-Laptops,OU=Groups,DC=example,DC=org")) {
+
+
+	#
+	# This may be a better place to call the files modules when using
+	# EAP-TLS, as it will only be called once, after the challenge-response
+	# iteration has completed.
+	#
+
+#	files
+
+
+	#
+	# Log all request attributes, plus TLS certificate details, to the
+	# detail auth_log. Again, this is just once per connection request, so
+	# may be preferable than in the outer authorize section. It is
+	# suggested that 'auth_log' also be in the outer post-auth and
+	# Post-Auth REJECT sections to log reply packet details, too.
+	#
+
+	auth_log
+
 }