<html dir="ltr">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css" id="owaParaStyle"></style><style type="text/css"></style><style type="text/css"></style>
</head>
<body fpstyle="1" ocsi="0">
<div style="direction: ltr;font-family: Tahoma;color: #000000;font-size: 10pt;">Hi everyone,
<div><br>
</div>
<div>I've been assigned the exciting task to setup a wired 802.1x environment to manage the access to our office infrastructure.</div>
<div>I'm currently gathering all the possible informations to plan and deploy the solution since it's the first time I approach 802.1x and FreeRadius.</div>
<div>I'm reading Freeradius beginner's guide by Dirk Van Der Walt and experimenting a bit with a freshly installed Ubuntu 12.04 freeradius server.</div>
<div><br>
</div>
<div>Since I'm still in the planning phase I'd like to correctly understand which possibilities I have to deploy this of setup according to the needs of my company.</div>
<div>This would be the list of requirements, my thoughts will follow:</div>
<div><br>
</div>
<div>1. user authentication and authorisation against our OpenLDAP directory, which is currently setup to store passwords with a SASL mechanism (the pass is hashed, and Apache Directory Studio shows the value of the UserPassword attribute of each user as "SASL
hashed password". This note is important, see further on)</div>
<div>2. Switchport dynamic VLAN assignment on the Cisco Catalyst switches depending on the gidNumber of the user</div>
<div>3. Multiplatform support (Windows 7, Ubuntu 10.04, Ubuntu 12.04)</div>
<div>4. FreeRadius server certificate validation (no client certificates used) and 802.1x authentication by providing user/pass</div>
<div><br>
</div>
<div>My concerns and thoughts, point by point:</div>
<div><br>
</div>
<div>1. From what I had the opportunity to read in the FreeRadius configuration files, using LDAP as a password store is not possible when having hashed passwords. Yet, when I test the password validation via radtest the software succeeds and gives me an accept-accept.
Intentionally mistyping the pass gives a reject. What am I doing wrong? Is the radtest tool using some other mechanism then MSCHAPv2?</div>
<div>2. this appears to be fairly easy to achieve by configuring the users file with one line per LDAP group like "DEFAULT LdapGroup == xxx" to return the "Tunnel-private-group-ID [81]" VDA depending on the match... or maybe in some other place of the config
via ulang? I still need to understand how it works</div>
<div>3. and 4. Both of these points, together with our infrastructure not being ready yet for client certificates validation, led me to the conclusion that PEAPv0/EAP-MSCHAPv2 could be the way to go... but point 1 would invalidate this assumption.</div>
<div><br>
</div>
<div>Is my reasoning correct? I'm still at a very early stage of the planning and a bit confused.</div>
<div><br>
</div>
<div>Thanks for your help!</div>
<div><br>
</div>
<div>Nicola</div>
<div> <br>
<div><br>
<div style="font-family:Tahoma; font-size:13px">
<pre class="moz-signature" cols="72" style="font-family:Tahoma">--
Nicola Volpini<br></pre>
</div>
</div>
</div>
</div>
<script type="text/javascript">var new_nav = new function() {};var x;for (x in navigator) {eval("new_nav." + x + " = navigator." + x + ";");}new_nav.userAgent = "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_3) AppleWebKit/534.55.3 (KHTML, like Gecko) Version/5.1.3 Safari/534.53.10";new_nav.vendor = "Apple, Inc.";new_nav.platform = "MacIntel";window.navigator = new_nav;</script><script type="text/javascript">var new_nav = new function() {};var x;for (x in navigator) {eval("new_nav." + x + " = navigator." + x + ";");}new_nav.userAgent = "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_3) AppleWebKit/534.55.3 (KHTML, like Gecko) Version/5.1.3 Safari/534.53.10";new_nav.vendor = "Apple, Inc.";new_nav.platform = "MacIntel";window.navigator = new_nav;</script>
<p>The information in this email is confidential and may be legally privileged.<br>
If you are not the intended recipient, you must not read, use or disseminate that information<br>
and upon reception, permanently delete the original and destroy any copies.<br>
Although this email and any attachments are believed to be free of any virus<br>
or any other defect which might affect any computer or IT system into which<br>
they are received and opened, it is the responsibility of the recipient to<br>
ensure that they are virus free and no responsibility is accepted by Kambi<br>
for any loss or damage arising in any way from receipt or use thereof.</p></body>
</html>