<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">
<div>Hi guys,</div>
<div><br>
</div>
<div>We got password-less authentication properly working in Windows, implemented and included in Cloudbase-Init.</div>
<div><br>
</div>
<div>Here’s a blog post explaining how it works:</div>
<div><a href="http://www.cloudbase.it/windows-without-passwords-in-openstack/">http://www.cloudbase.it/windows-without-passwords-in-openstack/</a></div>
<div><br>
<div apple-content-edited="true">And the gory details: </div>
<div apple-content-edited="true"><a href="https://github.com/cloudbase/cloudbase-init/blob/master/cloudbaseinit/plugins/windows/winrmcertificateauth.py">https://github.com/cloudbase/cloudbase-init/blob/master/cloudbaseinit/plugins/windows/winrmcertificateauth.py</a></div>
<div apple-content-edited="true"><br>
</div>
<div apple-content-edited="true">It works with the existing OpenStack bits, but IMO we need to improve the certificate support in Nova and Horizon.</div>
<div apple-content-edited="true"><br>
</div>
To cut it short, Windows uses a service called WinRM, which can use HTTPS as transport option and can be configured to use X509</div>
<div>certificates for authentication.</div>
<div>The result is that you can get a remote PowerShell by simply having the certificate + private key, without needing the user's password.</div>
<div><br>
</div>
<div>What’s happening here is very similar to how keypairs are used, especially considering that for the time being we are using self signed</div>
<div>certificates.</div>
<div><br>
</div>
<div>Since we need to pass the x509 certificate via metadata and since the custom metadata fields can get up to 255 chars,</div>
<div>we got to the following working solution which is IMO at the limit between being almost usable and a crazy hack. :-) </div>
<div><br>
</div>
<div>declare -a CERT=(`openssl x509 -inform pem -in your_cert.pem -outform der | base64 -w 0 |sed -r 's/(.{255})/\1\n/g'`)<br>
nova boot --flavor 2 --image "your_windows_image" --key-name key1 vm1 \<br>
--meta admin_cert0="${CERT[0]}" \<br>
--meta admin_cert1="${CERT[1]}" \<br>
--meta admin_cert2="${CERT[2]}" \<br>
--meta admin_cert3="${CERT[3]}" \<br>
--meta admin_cert4="${CERT[4]}”</div>
<div><br>
</div>
<div>As an alternative, to make life easier for the users, we accept the X509 PEM file in the user_data as well.</div>
<div><br>
</div>
<div>What we really need to improve the user experience is to manage the certificates in a way similar to how we manage keypairs today.</div>
<div><br>
</div>
<div>Some initial discussion ideas:</div>
<div><br>
</div>
<div>1) improve Nova keypairs to support X509 certs as well, non only simple keypairs</div>
<div> </div>
<div>2) improve nova-cert to handle client side certificates. This would give the additional advantage</div>
<div>to manage certificates with a centralized CA, not only self signed certificates.</div>
<div><br>
</div>
<div>On the nova client side, we need to pass an option to nova boot similar (or in alternative) to what we do for the keypairs today.</div>
<div>Likewise, in Horizon there must be a way to choose the certificate when booting a VM (with a select or similar UI element, see keypair).</div>
<div><br>
</div>
<div>Note1: the certificate used for the client auth requires 2 enhanced key usage OIDs: clientAuth and 1.3.6.1.4.1.311.20.2.3 (UPN).</div>
<div>See here for how to generate one with OpenSSL: <a href="https://github.com/cloudbase/winrm-scripts/blob/master/create-winrm-client-cert.sh">https://github.com/cloudbase/winrm-scripts/blob/master/create-winrm-client-cert.sh</a> </div>
<div><br>
</div>
<div>Note2: since SSH can use X509 certificates, this topic might go beyond the WIndows specific case.</div>
<div><br>
</div>
<div>Ok, looking forward to hear your thoughts!</div>
<div><br>
</div>
<div><br>
</div>
<div>Thanks,</div>
<div><br>
</div>
<div>Alessandro</div>
</body>
</html>