A blog post from our Service Factory:
Every year it gets a bit quieter between the days and we have time to test different topics in our lab.
This year my challenge was to deploy 802.1x certificates automatically on native Microsoft phones. Unfortunately, there is hardly any documentation on the subject. According to the datasheet all available phones should be able to do it, but there is no documentation about the practical implementation and I couldn't find any details in the usual blogs either. Accordingly, it was trial-and-error.
For testing, I had a Yealink MP56 Phone and a Poly CCX400 or CCX500 at my disposal. The configuration for the CCX series is so far identical that it should also work with a CCX600.
Since I had never held a native team phone from Yealink in my hands, I started with this one.
In the lab, I set up a new network, set the DHCP option to 160, and looked to see if the phone was reporting to my FTP server and what files were being requested.
Fortunately, the Yealink phone requested not only a specific configuration file for its MAC address, but also a "y0000000122.cfg". With this file I then created a template and was able to provide the phone with configuration parameters.
Among other things, ftp or http paths are specified where the phone can download the certificates. However, the private key of the certificate is then also located there in plain text. In the lab this is fine, but in a real production environment this should not be the case.
After a few hours I was able to get a Yealink phone with factory defaults into the network and it pulls a default firmware, sets the language, the timezone and the admin password. Then it downloads the certificate and enables 802.1x. Done. The phone is now ready for a user to log in.
I solved the security problem with the private key of the certificate on the FTP server by moving the files to a web server (IIS) and using the rewrite rules to allow only phones to access them. All access from web browsers is blocked and directory browsing is disabled.
Now that the infrastructure was in place, the same again with the poly phones. Here the research took many times longer and I was close to giving up several times. The Poly phones are much more complex to configure at first glance, but in the end even that worked.
With the Poly phones I wrote the certificates directly into the "shared.cfg" and stored the configuration files, as well as the firmware again on the hardened IIS.
Again, in the end, the same result as with the Yealink phone: put the Poly on the network with factory defaults and wait for it to pull a given firmware. Then the phone configures the language, time zone, admin password, downloads the certificate and enables 802.1x with EAP-TLS. This phone is also now ready for a user to log in.
The solution now runs fully automatically and new phones are prepared for users without manual intervention. After provisioning, the phones can be handed over to the users and connected to switch ports with 802.1x enabled.
Different virtual directories in IIS can be used to distribute different settings and certificates for different sites (e.g. countries).
To exchange a certificate, it is simply exchanged in IIS and the phones pull it at the latest at the next reboot. This can also be scheduled and triggered via the Teams Admin Center.
If you are interested in our solution, we will be happy to provide a white paper via our sales department and of course we will also support you with the configuration.
Just send us a note: info@alliance-teg.com :-)
Comments