The debug log you posted shows no User-Name in the session-state list.
Eh? Sorry Alan, but it does have one! See the quoted bits: (6) update {
(6) &outer.session-state::EAP-Channel-Binding-Message += &reply:EAP-Channel-Binding-Message[*] -> 0x02002a01a40648545450a524736572766963652e6d6f6f6e73686f742d706c617970656e2e74692e6a612e6e6574 (6) &outer.session-state::Reply-Message += &reply:Reply-Message[*] -> 'Bob has authenticated' (6) &outer.session-state::User-Name += &reply:User-Name[*] -> 'root' (6) } # update = noop (6) } # if (1) = noop (6) } # post-auth = noop (6) } # server inner-tunnel (6) Virtual server sending reply (6) EAP-Channel-Binding-Message = 0x02002a01a40648545450a524736572766963652e6d6f6f6e73686f742d706c617970656e2e74692e6a612e6e6574 (6) Reply-Message = "Bob has authenticated" (6) User-Name = "root" (6) eap_ttls: Got tunneled Access-Accept (6) eap_ttls: Sending tunneled reply attributes (6) eap_ttls: EAP-Channel-Binding-Message = 0x02002a01a40648545450a524736572766963652e6d6f6f6e73686f742d706c617970656e2e74692e6a612e6e6574 (6) eap: Sending EAP Request (code 1) ID 7 length 99 (6) eap: EAP session adding &reply:State = 0x99ee34c09fe92160 (6) [eap] = handled (6) } # authenticate = handled (6) Using Post-Auth-Type Challenge (6) Post-Auth-Type sub-section not found. Ignoring. (6) # Executing group from file /etc/raddb/sites-enabled/abfab-tr-idp (6) session-state: Saving cached attributes (6) Moonshot-Host-TargetedId := "33127397-1bb6-5e95-8859-dfe76acfba67@idp.test.assent" (6) Moonshot-Realm-TargetedId := "abd0d71b-7294-5423-86b1-3fae0bd7b33a@idp.test.assent" (6) Moonshot-TR-COI-TargetedId := "b40d0def-5b25-52bd-8d13-e6d22fa24648@idp.test.assent" (6) EAP-Channel-Binding-Message += 0x02002a01a40648545450a524736572766963652e6d6f6f6e73686f742d706c617970656e2e74692e6a612e6e6574 (6) Reply-Message += "Bob has authenticated" (6) User-Name += "root" (6) Sent Access-Challenge Id 189 from 0.0.0.0:2083 to 13.94.115.212:48186 length 0 : : (7) Restoring &session-state (7) &session-state:Moonshot-Host-TargetedId := "33127397-1bb6-5e95-8859-dfe76acfba67@idp.test.assent" (7) &session-state:Moonshot-Realm-TargetedId := "abd0d71b-7294-5423-86b1-3fae0bd7b33a@idp.test.assent" (7) &session-state:Moonshot-TR-COI-TargetedId := "b40d0def-5b25-52bd-8d13-e6d22fa24648@idp.test.assent" (7) &session-state:EAP-Channel-Binding-Message += 0x02002a01a40648545450a524736572766963652e6d6f6f6e73686f742d706c617970656e2e74692e6a612e6e6574 (7) &session-state:Reply-Message += "Bob has authenticated" (7) &session-state:User-Name += "root" : : (7) # Executing section post-auth from file /etc/raddb/sites-enabled/abfab-tr-idp (7) post-auth { (7) update { (7) &reply::Moonshot-Host-TargetedId += &session-state:Moonshot-Host-TargetedId[*] -> '33127397-1bb6-5e95-8859-dfe76acfba67@idp.test.assent' (7) &reply::Moonshot-Realm-TargetedId += &session-state:Moonshot-Realm-TargetedId[*] -> 'abd0d71b-7294-5423-86b1-3fae0bd7b33a@idp.test.assent' (7) &reply::Moonshot-TR-COI-TargetedId += &session-state:Moonshot-TR-COI-TargetedId[*] -> 'b40d0def-5b25-52bd-8d13-e6d22fa24648@idp.test.assent' (7) &reply::EAP-Channel-Binding-Message += &session-state:EAP-Channel-Binding-Message[*] -> 0x02002a01a40648545450a524736572766963652e6d6f6f6e73686f742d706c617970656e2e74692e6a612e6e6574 (7) &reply::Reply-Message += &session-state:Reply-Message[*] -> 'Bob has authenticated' (7) &reply::User-Name += &session-state:User-Name[*] -> 'root' (7) } # update = noop : : (7) Sent Access-Accept Id 83 from 0.0.0.0:2083 to 13.94.115.212:48186 length 0 (7) MS-MPPE-Recv-Key = 0x1ee8bbd31cd79fd4e98d946e946e1f976b7aaebd6e5412b4bab51b2e2d784c9c (7) MS-MPPE-Send-Key = 0x4de6d0ddcf7a725afc0a7e4b7fb2478b5c59a76ac5689342d33fbcdb4787f2c7 (7) EAP-Message = 0x03070004 (7) Message-Authenticator = 0x00000000000000000000000000000000 (7) User-Name = "@idp.test.assent" (7) Proxy-State = 0x30 (7) Moonshot-Host-TargetedId += "33127397-1bb6-5e95-8859-dfe76acfba67@idp.test.assent" (7) Moonshot-Realm-TargetedId += "abd0d71b-7294-5423-86b1-3fae0bd7b33a@idp.test.assent" (7) Moonshot-TR-COI-TargetedId += "b40d0def-5b25-52bd-8d13-e6d22fa24648@idp.test.assent" (7) EAP-Channel-Binding-Message += 0x02002a01a40648545450a524736572766963652e6d6f6f6e73686f742d706c617970656e2e74692e6a612e6e6574 (7) User-Name += "root"
This is the problem. There are *two* User-Name attributes now. 'root' came from the inner-tunnel as expected. The User-Name of '@idp.test.assent' is unexpected.
Hmm... if I set the inner reply with a User-Name, and then set "use_tunneled_reply = yes", then the inner User-Name is copied to the outer one as expected.
use_tunneled_reply is deprecated. We're using the 'new' way, using the session-state list. I've uploaded a set of files to https://www.dropbox.com/sh/tonkqtbxloyzb8d/AAAUWbTS1xzvsnPWY9gk6KR2a?dl=0 What you'll find there is a folder called 'fr3015-3017-username-glitches', in which you have 5 runs of exactly the same authentication set (and a compressed archive of all runs): 1. A run in FR 3.0.15, all three actors (APC, IDP and RP) in the correct 'default' state: - fr3015-apclog-apc-default-rp-default-idp-default - fr3015-idplog-apc-default-rp-default-idp-default - fr3015-rplog-apc-default-rp-default-idp-default This state shows a complete successful authentication run. It returns as part of the Access-Accept from the IdP to the RP the User-Name value of 'root'. That is overwritten on the RP to 'moonshot'. To see which packets go where at what time, see the logs in the 'fr3015-with-ts' folder, which were run with the -fxxx parameter but the date (not time) and 'Debug' and 'Info' messages removed. 2. A run in FR 3.0.17, all three actors (APC, IDP and RP) in the correct 'default' state (as upgraded to from 3.0.15): - fr3017-apclog-apc-default-rp-default-idp-default - fr3017-idplog-apc-default-rp-default-idp-default - fr3017-rplog-apc-default-rp-default-idp-default Here you will only find APC and RP interacting. Because APC returns *two* User-Name attributes ('@test.assent' and the real value), the whole flow fails. 3. A run in FR 3.0.17, the APC modified, IDP and RP in 'default' state: - fr3017-apclog-apc-mod-rp-default-idp-default - fr3017-idplog-apc-mod-rp-default-idp-default - fr3017-rplog-apc-mod-rp-default-idp-default Here you will find a complete successful authentication run. The APC has been modified with the 'update reply {...}' fix in post-auth. However, IDP returns *two* User-Name attributes ('@idp.test.assent' and the value 'root'), and the RP rewrites the first to 'moonshot'. 4. A run in FR 3.0.17, the APC and RP modified, IDP in 'default' state: - fr3017-apclog-apc-mod-rp-mod-idp-default - fr3017-idplog-apc-mod-rp-mod-idp-default - fr3017-rplog-apc-mod-rp-mod-idp-default Here you will find a complete successful authentication run. The APC and RP have been modified with the 'update reply {...}' fix in post-auth. However, IDP returns *two* User-Name attributes ('@idp.test.assent' and the value 'root'), the RP deletes *all* instances of User-Name and sets one of 'moonshot'. 5. A run in FR 3.0.17, all three actors (APC, IDP and RP) modified: - fr3017-apclog-apc-mod-rp-mod-idp-mod - fr3017-idplog-apc-mod-rp-mod-idp-mod - fr3017-rplog-apc-mod-rp-mod-idp-mod Here you will find a failure again, because the IDP deletes the User-Name that is necessary for the APC to authorize a connection. The flow fails, the RP retries and eventually has to give up. What I *would* expect is to see the flow in FR 3.0.15 in FR 3.0.17. I hope this helps. With Regards Stefan Paetow Consultant, Trust and Identity t: +44 (0)1235 822 125 gpg: 0x3FCE5142 xmpp: stefanp@jabber.dev.ja.net skype: stefan.paetow.janet jisc.ac.uk Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under Company No. 5747339, VAT No. GB 197 0632 86. Jisc’s registered office is: One Castlepark, Tower Hill, Bristol, BS2 0JA. T 0203 697 5800.