The Intel AMT Developer Tool Kit (DTK) is now over a year old and by many accounts, the most popular software package for using Intel AMT that exists today. As I work on improvements and new features I also get to interact with my users, developers, IT departments, testers, etc. I also come across many common ideas for how Intel AMT should be improved. Today I decided to compile my own list of changes I would make to improve Intel AMT. Even if I work at Intel, I have no special access or power over what gets changed, so it’s important that users of Intel AMT make your voices heard if you think you have changes you need made.
1. No TLS, Serial-over-LAN/IDE-R password in the clear. As many of you have discovered, when using Intel AMT in small business or enterprise mode without TLS, the login username and password is sent on the network in the clear when the administrator performs a serial-over-LAN or IDE redirect operation. With so many coffee shops, schools, Internet cafes playing around with Intel AMT features, this could be a big problem. Imagine a classroom with a few vPro computers with AMT setup in SMB mode by an unsuspecting teacher. A student running a packet sniffer, obtaining the password and rebooting AMT computers remotely. This can be avoided by setting up TLS using Intel AMT Director, but this should not be problem in the first place. The HTTP digest used for web pages could easily be adapted and used.
2. Allow TLS in SMB mode. This is a long time feature request that is somewhat related to the first issue. In my work with Intel AMT, I can do everything I need to setup TLS in SMB mode except enabling it. Allowing administrators to setup server-side authenticated TLS would be very easy to add to Intel AMT and would provide improved security with almost no work. In fact, Intel AMT Commander could just prompt the administrator on first connect if he or she want to enable TLS when a non-TLS SMB computer is found. A new root certificate would be generated if none already exist. Strictly speaking, it would not provide “bank level” security, but would go a long way for shops, schools, small business owners that have more to think about than understanding secure manageability.
3. Release the SOL/IDE-R redirection source code. The library called “IMRSDK.dll” is compiled by Intel and not available in source code form. It’s available in Windows and Linux but it has been a problem for people trying to port this feature on to other platforms. It’s also a problem because this library is far from perfect and I would be the first to make changes to it. One of the most critical changes I would make involves knowing if the Serial-over-LAN is connected or not. Imagine how annoying it is to have the SOL connection drop and that application not know about it. Intel AMT Terminal will show “Connected” at the top even when it’s really not. I also want a debugging feature to know exactly what is going on, people report in forums and privately to me that SOL has problems and I have no way to help. My list does not end there; I have more changes I really need made.
4. Make Intel AMT discovery and connection easier. Some Intel AMT software have a discovery feature that attempts to sweep a network to find Intel AMT computers and add them to a management console. To make it easier on the user, Intel AMT Commander also attempts to automatically detect that type of AMT computer it’s talking to. Once you discover a computer, the work is not done. Is the computer setup with TLS? Is it in WSMAN only mode? Is it using TLS mutual-auth? Are you talking to LMS? What version is this? The Intel AMT DTK has an elaborate system to attempt gather this data when a user connects. With new version of Intel AMT, transition to WSMAN and more, it’s getting more and more difficult to correctly detect and connect to all versions of Intel AMT. Developers looking at the DTK’s connection algorithm will be stunned, we need to simplify this process.
5. Get permitted access realms upon connection. So you setup Intel AMT with various user accounts, one for asset monitoring only, one for packet control, another for remote repair. When software like Intel AMT Commander connects to Intel AMT using one of these accounts, it has no idea what types of permissions this account has. As a result, the software is left to assume it has all rights, or fail with an error when things start to go wrong. I don’t think it would be unreasonable to be able to query the allowed realms upon connection for the account currently being used. This would make it easy for Intel AMT Commander to remove from the UI features that are not allowed.
Of course, being an avid fan of Intel AMT, I could write many things I like about it, just look at my many blogs. It’s my hope that this list will spur discussion and action. If you read this, take the time to write a small comment saying which one of these would want fixed first, or tell me if you have your own issue.
Ylian (Intel AMT Blog)