I'm having the same issues. I got past the profile errors (which was no small feat without any working examples or functional documentation), but ultimately I get an access violation reading 0x000... from TtlsCfg.dll.
I can give you a few clues here, where you'll get past the config errors, but eventually will hit the access violation in TtlsCfg.dll.
In C:\Windows\schemas\, you will find two folders: EAPHost and EAPMethods. Inside those folders, you will find the schemas for all of these xml namespaces, so that will help resolve some of the mystery (especially for EapTtlsUserPropertiesv1, which has no documentation
online).
Now that you're familiar with that, take a close look at EapTtlsUserPropertiesv1. The element name under which Username and Password go, is "eapTtls" (case sensitive). So, in the example above (from Fei Xue), that would fail with a non-zero return
code when passed to WlanSetProfileEapXmlUserData(). When you get to <EapTtls... you need another level there. Like this...
<EapTtls xmlns=\"http://www.microsoft.com/provisioning/EapTtlsUserPropertiesV1\">
<eapTtls>
<Username>eapauto</Username>
<Password>!password1</Password>
</eapTtls>
</EapTtls>
Don't get too excited, though. That will get you past the return code errors, and will lead you down the path of extreme frustration with access violation in TtlsCfg.dll. I still have no been able to solve that.
However, I do have another suspicion... Notice that EapTtlsUserCredentialsv1 imports BaseEapUserPropertiesv1 -- like a parent/child class relationship. Go ahead and open that up, you'll find it in those folders I mentioned. Now, direct your eyes at this part:
<xs:element name="EapType" type="BaseEapTypeParameters" abstract="true"/>
<xs:element name="Identity" type="xs:string" abstract="true" />
I don't claim to know exactly how this stuff works, but I do understand classes with abstract elements -- and these xml notations smell a lot like that. So, what we have here is a child class, EapTtlsUserPropertiesv1 that inherits from a parent class with abstract
elements. But it's not overriding/implementing them. Oops!
To back up this hunch... since PEAP works, open up MsPeapUserPropertiesv1. Take a look at these lines:
<xs:element name="RoutingIdentity" substitutionGroup="baseEap:Identity"/>
<xs:element name="EapType" substitutionGroup="baseEap:EapType">
You can follow those further, but basically, peap has the substitutionGroup attribute in there, which appears to be implementing those abstract elements. And, since MSCHAPv2 is usually used with PEAP, you can open up that one and see similar things in there:
<xs:element name="Username" substitutionGroup="baseEap:Identity"/>
<xs:element name="EapType" substitutionGroup="baseEap:EapType">
The mschapv2 stuff goes in a baseEap:Eap node tree below the MsPeap tree, further overriding those abstracts. EapTtlsUserPropertiesv1 is not doing any of that.
I've been poking around to see if I can unravel some of those other APIs shown in the stack dump above, such as EapHostPeerCredentialsXml2Blob, to try to figure out how to construct the blob directly and use WlanSetProfileEapUserData() with the blob instead
of WlanSetProfileEapXmlUserData() with the xml; since something looks broken with the xml interpretation for Ttls -- either because the EapTtlsUserPropertiesv1 schema is wrong, or because those xml interpretation apis have a problem. If the underlying classes
and code in TtlsCfg.dll are broken, then none of this will help. I just don't know.
And I'm not so confident to rule out the possibility that we're messing up this ttls xml because we're not burying mschapv2 within it, as is done with PEAP -- but the EapTtlsUserPropertiesv1 doesn't seem to have the same extensions section available to be able
to do that.
Help from MS would be greatly appreciated here. As with the poster IncPlusPlus above, all I run into on this problem are dead threads as well.
