I don't understand how a User-Name attribute is being added into the *reply* when using EAP. To replicate this, I have the default 3.0.12 config with the "steve" user uncommented, and with radtest it behaves as expected: no User-Name in the reply. But if I exercise this account using eapol_test, I see the outer User-Name attribute is in the Access-Accept: (29) Sent Access-Accept Id 10 from 127.0.0.1:1812 to 127.0.0.1:38985 length 0 (29) MS-MPPE-Recv-Key = 0xb581e1ac47471ad3952989c90595a23d8b851827abebc4089ef09574e9d69246 (29) MS-MPPE-Send-Key = 0x244f2954e441937015fa8aa44a36fc94d3c473fbb86ae9498b93f3524b126d37 (29) EAP-Message = 0x030a0004 (29) Message-Authenticator = 0x00000000000000000000000000000000 (29) User-Name = "anonymous" << HERE And if I uncomment these sections from inner-tunnel: update { &outer.session-state: += &reply: } update outer.session-state { MS-MPPE-Encryption-Policy !* ANY MS-MPPE-Encryption-Types !* ANY MS-MPPE-Send-Key !* ANY MS-MPPE-Recv-Key !* ANY Message-Authenticator !* ANY EAP-Message !* ANY Proxy-State !* ANY } then the reply has *two* User-Name attributes: (10) Sent Access-Accept Id 10 from 127.0.0.1:1812 to 127.0.0.1:53750 length 0 (10) MS-MPPE-Recv-Key = 0x0bd13ceb1f41f1cd7acbc81339d64f6a5411d5c507153eacefe6f7b51201956c (10) MS-MPPE-Send-Key = 0x619ca77357791b4b88a270e610dd8716cce3faebd7973dc07b18aa2cb625611a (10) EAP-Message = 0x030a0004 (10) Message-Authenticator = 0x00000000000000000000000000000000 (10) User-Name = "anonymous" << HERE (10) Service-Type += Framed-User (10) Framed-Protocol += PPP (10) Framed-IP-Address += 172.16.3.33 (10) Framed-IP-Netmask += 255.255.255.0 (10) Framed-Routing += Broadcast-Listen (10) Framed-Filter-Id += "std.ppp" (10) Framed-MTU += 1500 (10) Framed-Compression += Van-Jacobson-TCP-IP (10) User-Name += "steve" << HERE Any clues as to what's going on here? RFC2865 (section 5.44) says that an Access-Accept may only contain 0 or 1 User-Name attributes. I could filter them both out, but I'd like to understand how they are getting there in the first place. Thanks, Brian.