Univention Bugzilla – Bug 56670
VLAN-ID is not assigned after successful login with mix-cased username on Radius server
Last modified: 2024-02-04 01:23:36 CET
This behaviour is reproducible with: UCS: 5.0-4 errata798 Installed: adconnector=12.0 dhcp-server=12.0 radius=5.0 samba4=4.16 Description of the behaviour: Users who consistently wrote their usernames in lower case were assigned to the correct VLAN as configured in LDAP. Users who wrote their usernames with at least one capitalized letter will be authorized but the correct VLAN will not be assigned. They don't get any error message because authorization did work. It may be that on some devices the first letter in text fields like the login field is automatically always capitalized. Users don't expect this, because they used to Windows/Samba logins where a capital letter in the login name is not a problem. Result on test system with username written in lower case: root@mf1primary:~# radtest testuser1 univention localhost 500 testing123 Sent Access-Request Id 222 from 0.0.0.0:36507 to 127.0.0.1:1812 length 79 User-Name = "testuser1" User-Password = "univention" NAS-IP-Address = 10.201.0.232 NAS-Port = 500 Message-Authenticator = 0x00 Cleartext-Password = "univention" Received Access-Accept Id 222 from 127.0.0.1:1812 to 127.0.0.1:36507 length 90 Reply-Message = "DEBUG: Assigning VLAN-ID from user / computer object" Tunnel-Type:0 = VLAN Tunnel-Medium-Type:0 = IEEE-802 Tunnel-Private-Group-Id:0 = "11" root@mf1primary:~# Result on the same test system with username written with one capital letter: root@mf1primary:~# radtest Testuser1 univention localhost 500 testing123 Sent Access-Request Id 187 from 0.0.0.0:49219 to 127.0.0.1:1812 length 79 User-Name = "Testuser1" User-Password = "univention" NAS-IP-Address = 10.201.0.232 NAS-Port = 500 Message-Authenticator = 0x00 Cleartext-Password = "univention" Received Access-Accept Id 187 from 127.0.0.1:1812 to 127.0.0.1:49219 length 20 root@mf1primary:~# Unfortunately there is no hint for the user that something is going wrong. The users gets authorized and thinks everything should be fine, but the expected network resources are not reachable (in most cases the access to the internet is not available). There are two possible workarounds to avoid the situation. Workaround 1: The ucr variable "freeradius/vlan-id" can be set and if the network design of the customer allows this. If it's just about to get the right VLAN-ID for internet access, this could be a workaround. ucr set freeradius/vlan-id='123' Workaround 2: Activate these three lines in the policy file /etc/freeradius/3.0/policy.d/filter to disallow mix-cased usernames. This is not a solution, but prevents the situation. At least the user gets an error message and is not confused, because authorization will be prevented when the username was not written completely with lower cases. snip from /etc/freeradius/3.0/policy.d/filter filter_username { if (&User-Name) { # # reject mixed case e.g. "UseRNaMe" # if (&User-Name != "%{tolower:%{User-Name}}") { reject }
*** Bug 55960 has been marked as a duplicate of this bug. ***
*** Bug 56674 has been marked as a duplicate of this bug. ***
(In reply to Wolfgang Bayrhof from comment #0) > This behaviour is reproducible with: > UCS: 5.0-4 errata798 > Installed: adconnector=12.0 dhcp-server=12.0 radius=5.0 samba4=4.16 > > Description of the behaviour: > Users who consistently wrote their usernames in lower case were assigned to > the correct VLAN as configured in LDAP. Users who wrote their usernames with > at least one capitalized letter will be authorized but the correct VLAN will > not be assigned. They don't get any error message because authorization did > work. It may be that on some devices the first letter in text fields like > the login field is automatically always capitalized. Users don't expect > this, because they used to Windows/Samba logins where a capital letter in > the login name is not a problem. > > > Result on test system with username written in lower case: > > root@mf1primary:~# radtest testuser1 univention localhost 500 testing123 > Sent Access-Request Id 222 from 0.0.0.0:36507 to 127.0.0.1:1812 length 79 > User-Name = "testuser1" > User-Password = "univention" > NAS-IP-Address = 10.201.0.232 > NAS-Port = 500 > Message-Authenticator = 0x00 > Cleartext-Password = "univention" > Received Access-Accept Id 222 from 127.0.0.1:1812 to 127.0.0.1:36507 length > 90 > Reply-Message = "DEBUG: Assigning VLAN-ID from user / computer object" > Tunnel-Type:0 = VLAN > Tunnel-Medium-Type:0 = IEEE-802 > Tunnel-Private-Group-Id:0 = "11" > root@mf1primary:~# > > Result on the same test system with username written with one capital letter: > > root@mf1primary:~# radtest Testuser1 univention localhost 500 testing123 > Sent Access-Request Id 187 from 0.0.0.0:49219 to 127.0.0.1:1812 length 79 > User-Name = "Testuser1" > User-Password = "univention" > NAS-IP-Address = 10.201.0.232 > NAS-Port = 500 > Message-Authenticator = 0x00 > Cleartext-Password = "univention" > Received Access-Accept Id 187 from 127.0.0.1:1812 to 127.0.0.1:49219 length > 20 > root@mf1primary:~# > > Unfortunately there is no hint for the user that something is going wrong. > The users gets authorized and thinks everything should be fine, but the > expected network resources are not reachable (in most cases the access to > the internet is not available). There are two possible workarounds to avoid > the situation. > > Workaround 1: > The ucr variable "freeradius/vlan-id" can be set and if the network design > of the customer allows this. If it's just about to get the right VLAN-ID for > internet access, this could be a workaround. > > ucr set freeradius/vlan-id='123' > > Workaround 2: > Activate these three lines in the policy file > /etc/freeradius/3.0/policy.d/filter to disallow mix-cased usernames. This is > not a solution, but prevents the situation. At least the user gets an error > message and is not confused, because authorization will be prevented when > the username was not written completely with lower cases. > > snip from /etc/freeradius/3.0/policy.d/filter > > filter_username { > if (&User-Name) { > # > # reject mixed case e.g. "UseRNaMe" > # > if (&User-Name != "%{tolower:%{User-Name}}") { > reject > } Any update on this? I feel like this is a security risk.