I am using a recent 2.0.0-pre cvs snapshot. For 802.1x authentication AD is querried for a valid machine account and VLAN, which the ldap modules put into the radius-attribute Huntgroup-Name. The client authenticates via a certificate. Everything works as expected. Nevertheless someone inspecting the switch logs found: 12277052: .Sep 26 13:33:45.914: RADIUS: Received from id 1645/86 139.25.78.162:1812, *Access-Challenge,* len 1130 12277053: .Sep 26 13:33:45.914: RADIUS: authenticator 41 6D FD 2B B1 E6 81 32 - 92 3A 05 C1 96 B9 A5 E9 12277054: .Sep 26 13:33:45.914: RADIUS: *Tunnel-Private-Group[81] 18 "VL-SBS-AD02-0001" *12277055: .Sep 26 13:33:45.914: RADIUS: *Tunnel-Medium-Type [65] 6 00:ALL_802 [6] *12277056: .Sep 26 13:33:45.914: RADIUS: *Tunnel-Type [64] 6 00:VLAN [13] *12277057: .Sep 26 13:33:45.914: RADIUS: EAP-Message [79] 255 and claimed, the Access-Challenge with Tunnel-Private-Group, Tunnel-Medium-Type etc. are not RFC compatible. I can see those values in radiusd -AX, too, but didn't care. My question is: Is he right? If so: How would I have to change the configuration? In my sites-enabeld/default I have: ... # ldap1/2 set control:Huntgroup-Name. redundant { ldap1 ldap2 } ##################################################################################################################################### if ("%{sqlnastype:SELECT vl_vlan from vlan where vl_vlan = '%{control:Huntgroup-Name}' and vl_nasname='%{NAS-IP-Address}'}" == "%{control:Huntgroup-Name}" ) { # das vlan gibt es auf dem swicht update reply { Tunnel-Private-Group-ID ="%{control:Huntgroup-Name}" Tunnel-Medium-Type = IEEE-802 Tunnel-Type = VLAN } } .. This works as expected. Sending Access-Challenge of id 135 to 172.31.110.149 port 1645^M Tunnel-Private-Group-Id:0 = "VL-SBS-AD02-0001"^M Tunnel-Medium-Type:0 = IEEE-802^M Tunnel-Type:0 = VLAN^M EAP-Message = 0x0104040a0dc000001860160301004a02000046030146fa71a8d8d8395908fa88327d699ee4477b8e014f81fc6f5aabfabb26dda89a204f927ec5aaa134ac60f488278826fbd8be697e5826f45b2890e527d58ca26a0a00040016030113710b00136d00136a0005f6308205f2308204daa003020102020a136547850002003ae484300d06092a864886f70d01010505003081f6310b300906035504061302444531133011060a0992268993f22c64011916036e657431173015060a0992268993f22c64011916077369656d656e733110300e060355040a13075369656d656e7331453043060355040b133c49737375696e6720434120666f72206d6163^M EAP-Message = 0x68696e652063657274696669636174657320696e20746865205369656d656e7320414420666f72657374313a3038060355040b1331436f7079726967687420284329205369656d656e73204147203230303320416c6c20726967687473207265736572766564312430220603550403131b5369656d656e732049737375696e6720434120436c617373204144301e170d3037303832323233333131325a170d3038303231383233333131325a3025312330210603550403131a64653730313874632e77773930312e7369656d656e732e6e657430819f300d06092a864886f70d010101050003818d0030818902818100d420d44e29fdfd018e8ff279b4^M EAP-Message = 0x04d0421c8612c6cd6ba909bb50feca6a71089e6212ef9ae86a3a0cd12f201b25e62ec7395e1365a8bac4477551fed6c41183e2210a3b524e013f80952f7f7efef179f6b48d1a7e219a8e0e789d561b8472485f7792a6e51514018b40e1f90feb314aff3d7a55baceb56b72af1d1bb04ee8a4a30203010001a38202d4308202d0301d0603551d0e041604143349edcf20cbe55a68d010a8df8878bbce1714e4303306092b060104018237150a04263024300a06082b06010505070302300a06082b06010505070301300a06082b06010505080202300b0603551d0f0404030205a030270603551d250420301e06082b0601050507030206082b06010505^M EAP-Message = 0x07030106082b06010505080202303c06092b0601040182371507042f302d06252b060104018237150887e4bc2b85a7c80a85d19529a08c6d819ffa1381219eaf36869ee33d020164020103301f0603551d2304183016801453cf2cd0fe413db6c4731640813764d8702909993081e50603551d1f0481dd3081da3081d7a081d4a081d18681ce6c6461703a2f2f2f434e3d5369656d656e7325323049737375696e672532304341253230436c61737325323041442832292c434e3d6d63686d393335612c434e3d4344502c434e3d5075626c69632532304b657925323053657276696365732c434e3d53657276696365732c434e3d436f6e6669677572^M EAP-Message = 0x6174696f6e2c44433d7369656d656e732c44433d6e65^M Message-Authenticator = 0x00000000000000000000000000000000^M State = 0xcf369d304b83244706a446310ed5b92e^M Finished request 1 state 5^M Going to the next request^M The complete output can be found at http://www.wegener-net.de:/freeradius Norbert Wegener
Norbert Wegener wrote:
... The client authenticates via a certificate. Everything works as expected. Nevertheless someone inspecting the switch logs found: ... and claimed, the Access-Challenge with Tunnel-Private-Group, Tunnel-Medium-Type etc. are not RFC compatible.
Yes.
I can see those values in radiusd -AX, too, but didn't care.
My question is: Is he right? If so: How would I have to change the configuration?
Ideally, the attributes in the reply should be sent ONLY on Access-Accept. i.e. the configuration should NOT update the reply until it has determined that the user has been authenticated. This involves moving most of the policy from the "authorize" section to the "post-auth" section.
In my sites-enabeld/default I have: ... # ldap1/2 set control:Huntgroup-Name.
redundant {
Which section? authorize? Alan DeKok.
participants (2)
-
Alan DeKok -
Norbert Wegener