I've been working on a scenario with ACS 4.2 (trial) for Proof of Concept to a customer of ACS's abilities.
His intended network plan is to use Vista Laptops doing Machine authentication only towards a ACS server integrated with a non-microsoft LDAP server. The mechanism of choice is EAP-TLS.
We've set up the PKI on the right places and it is all up. We do manage to get a user certificate on the PC, authenticate via ACS to the LDAP repository, and everything is good.
The problem that we are facing is when we want to move to do machine authentication, the behaviour is inconsistent. I'll explain:
When the first authentication is done, the EAP-Identity requests are always prepended with a "host/". What we see is that the CN of a certificate is TEST, and the Identity request appears as host/TEST. This is no problem to LDAP, as we can get rid of the "host/" part to do the user matching and in fact it does match. After TLS handshake (certificates are ok), ACS tries to check CSDB (the internal ACS db) and afterwards it will follow the unknown user policy and query LDAP.
All of this appears to be successful the first time.
If we disassociate the machine, the problems start. The accounting STOP message is never sent.
Any new authentication will fail with a message that CS user is invalid. The AUTH log shows that ACS will never try again to check LDAP, and invalidates the user right after CSDB check. In fact if we do see the reports for RADIUS, the authenticated user is host/TEST, but if we check the dynamic users, only TEST appears. Even disabling caching for dynamic users the problem remains.
Does anyone have an idea on how to proceed? If it was possible to handle the machine authentication without the "host/" part, that would be great, as it works.
My guess is that ACS is getting confused with the host/, as I'm seeing its AUTH logs and I do see some messages like UDB_HOST_DB_FAILURE, after UDB_USER_INVALID.
IF someone can give me a pointer on how to make this work, or if I'm hitting a bug in ACS.