Hello List, A few years ago I inherited a FreeRADIUS environment, and it has been more or less trouble free for the whole time. In mid-December, however, we started getting reports of authentication failures from computers that were joined to our Active Directory environment and only those computers. Previously we've been having no issues authenticating people with username. AD\username. and username@realm, but on around the 16th people with the AD\username format started getting authentication failures. We're running RHEL6 with the distro supplied freeradius binary (freeradius-2.2.6-6.el6_7.x86_64) and haven't made any changes to anything besides system updates in over a year, and it has been working perfectly up until now. Here's a relevant log snippet that appears to describe the issue, but I have no idea where to start looking for a solution. +group authorize { ++[preprocess] = ok ++[mschap] = noop ++[digest] = noop [suffix] No '@' in User-Name = "podia-user", looking up realm NULL [suffix] Found realm "NULL" [suffix] Adding Realm = "NULL" [suffix] Authentication realm is LOCAL. ++[suffix] = ok [eap] EAP packet type response id 1 length 18 [eap] No EAP Start, assuming it's an on-going EAP conversation ++[eap] = updated [files] users: Matched entry DEFAULT at line 50 ++[files] = ok ++[expiration] = noop ++[logintime] = noop +} # group authorize = updated Found Auth-Type = EAP # Executing group from file /etc/raddb/sites-enabled/default +group authenticate { [eap] Identity (AD\podia-user) does not match User-Name (podia-user). Authentication failed. [eap] Failed in handler ++[eap] = invalid +} # group authenticate = invalid Thanks in advance for any advice, -mat houser
On Dec 29, 2015, at 11:11 AM, Migo Pod <migopod@gmail.com> wrote:
Previously we've been having no issues authenticating people with username. AD\username. and username@realm, but on around the 16th people with the AD\username format started getting authentication failures.
What changed on the 16th?
We're running RHEL6 with the distro supplied freeradius binary (freeradius-2.2.6-6.el6_7.x86_64) and haven't made any changes to anything besides system updates in over a year, and it has been working perfectly up until now.
Things don't change by magic. *Something* changed.
Here's a relevant log snippet that appears to describe the issue, but I have no idea where to start looking for a solution. ... [eap] Identity (AD\podia-user) does not match User-Name (podia-user).
Post the FULL debug log, including the packet that the server received. Alan DeKok.
The change would have been whatever changed with yum-update, which ran on the 16th, and did include the freeradius, freeradius-utils and freeradius-mysql packages, but according to the RedHat change logs those packages were updated in September to fix the miscalculated MPPE keys with TLS 1.2 and nothing beyond that. Apart from running updates, the only thing we typically ever is adding new access points in clients.conf. Thanks, -mat Full debug: Waking up in 2.6 seconds. rad_recv: Access-Request packet from host 172.18.255.6 port 20002, id=254, length=162 NAS-Port-Id = "AP1306/2" Calling-Station-Id = "6C-88-14-54-69-28" Called-Station-Id = "00-26-3E-8D-79-C1:UWMWiFi" Service-Type = Framed-User EAP-Message = 0x020100120141445c706f6469612d75736572 User-Name = "AD\\podia-user" NAS-Port = 64901 NAS-Port-Type = Wireless-802.11 NAS-IP-Address = 172.18.255.6 NAS-Identifier = "Juniper" Message-Authenticator = 0xe3d83b401df09685c4df6a885095fa4f # Executing section authorize from file /etc/raddb/sites-enabled/default +group authorize { ++[preprocess] = ok ++[mschap] = noop ++[digest] = noop [suffix] No '@' in User-Name = "podia-user", looking up realm NULL [suffix] Found realm "NULL" [suffix] Adding Realm = "NULL" [suffix] Authentication realm is LOCAL. ++[suffix] = ok [eap] EAP packet type response id 1 length 18 [eap] No EAP Start, assuming it's an on-going EAP conversation ++[eap] = updated [files] users: Matched entry DEFAULT at line 50 ++[files] = ok ++[expiration] = noop ++[logintime] = noop +} # group authorize = updated Found Auth-Type = EAP # Executing group from file /etc/raddb/sites-enabled/default +group authenticate { [eap] Identity (AD\podia-user) does not match User-Name (podia-user). Authentication failed. [eap] Failed in handler ++[eap] = invalid +} # group authenticate = invalid Failed to authenticate the user. Login incorrect: [podia-user] (from client 172.18.255.6 port 64901 cli 6C-88-14-54-69-28) Using Post-Auth-Type REJECT # Executing group from file /etc/raddb/sites-enabled/default +group REJECT { [attr_filter.access_reject] expand: %{User-Name} -> podia-user attr_filter: Matched entry DEFAULT at line 11 ++[attr_filter.access_reject] = updated +} # group REJECT = updated Delaying reject of request 55 for 1 seconds On Tue, Dec 29, 2015 at 10:21 AM, Alan DeKok <aland@deployingradius.com> wrote:
On Dec 29, 2015, at 11:11 AM, Migo Pod <migopod@gmail.com> wrote:
Previously we've been having no issues authenticating people with username. AD\username. and username@realm, but on around the 16th people with the AD\username format started getting authentication failures.
What changed on the 16th?
We're running RHEL6 with the distro supplied freeradius binary (freeradius-2.2.6-6.el6_7.x86_64) and haven't made any changes to anything besides system updates in over a year, and it has been working perfectly up until now.
Things don't change by magic. *Something* changed.
Here's a relevant log snippet that appears to describe the issue, but I have no idea where to start looking for a solution. ... [eap] Identity (AD\podia-user) does not match User-Name (podia-user).
Post the FULL debug log, including the packet that the server received.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Dec 29, 2015, at 11:39 AM, Migo Pod <migopod@gmail.com> wrote:
The change would have been whatever changed with yum-update, which ran on the 16th, and did include the freeradius, freeradius-utils and freeradius-mysql packages, but according to the RedHat change logs those packages were updated in September to fix the miscalculated MPPE keys with TLS 1.2 and nothing beyond that.
Clearly there was something beyond that.
Full debug: Waking up in 2.6 seconds. rad_recv: Access-Request packet from host 172.18.255.6 port 20002, id=254, length=162 NAS-Port-Id = "AP1306/2" Calling-Station-Id = "6C-88-14-54-69-28" Called-Station-Id = "00-26-3E-8D-79-C1:UWMWiFi" Service-Type = Framed-User EAP-Message = 0x020100120141445c706f6469612d75736572 User-Name = "AD\\podia-user"
Which shows that the User-Name is correct.
NAS-Port = 64901 NAS-Port-Type = Wireless-802.11 NAS-IP-Address = 172.18.255.6 NAS-Identifier = "Juniper" Message-Authenticator = 0xe3d83b401df09685c4df6a885095fa4f # Executing section authorize from file /etc/raddb/sites-enabled/default +group authorize { ++[preprocess] = ok ++[mschap] = noop ++[digest] = noop [suffix] No '@' in User-Name = "podia-user", looking up realm NULL [suffix] Found realm "NULL" [suffix] Adding Realm = "NULL" [suffix] Authentication realm is LOCAL. ++[suffix] = ok
Something there is re-writing the User-Name to remove the "AD" portion. Check the configuration of the "suffice" module. Does it have "strip = yes" ?
[eap] EAP packet type response id 1 length 18 [eap] No EAP Start, assuming it's an on-going EAP conversation ++[eap] = updated [files] users: Matched entry DEFAULT at line 50
Does that entry strip the user name?
[eap] Identity (AD\podia-user) does not match User-Name (podia-user).
The User-Name has been re-written from "AD\podia-user" to "podia-user". It doesn't happen by magic. Something has updated it. Alan DeKok.
In proxy.conf all of the defined realms have nostrip included, and the only thing I can find that explicitly rewrites anything is a directive in the NULL realm that sets Stripped-User-Name to mschap:User-Name when the User-Name matches a /host\/[^\.].(.+)/ regex, and that's been in there since at least 2013. I've tried removing that clause from the realm and it didn't appear to affect anything. Other than that, I can't find anything that sets User-Name to anything at all. Of course things changed on the 16th when updates ran, but none of the files in /etc/raddb were modified since yum doesn't overwrite modified files, and the rpm chagnelogs aren't being particularly helpful. Thanks, -mat On Tue, Dec 29, 2015 at 10:59 AM, Alan DeKok <aland@deployingradius.com> wrote:
On Dec 29, 2015, at 11:39 AM, Migo Pod <migopod@gmail.com> wrote:
The change would have been whatever changed with yum-update, which ran on the 16th, and did include the freeradius, freeradius-utils and freeradius-mysql packages, but according to the RedHat change logs those packages were updated in September to fix the miscalculated MPPE keys
with
TLS 1.2 and nothing beyond that.
Clearly there was something beyond that.
Full debug: Waking up in 2.6 seconds. rad_recv: Access-Request packet from host 172.18.255.6 port 20002, id=254, length=162 NAS-Port-Id = "AP1306/2" Calling-Station-Id = "6C-88-14-54-69-28" Called-Station-Id = "00-26-3E-8D-79-C1:UWMWiFi" Service-Type = Framed-User EAP-Message = 0x020100120141445c706f6469612d75736572 User-Name = "AD\\podia-user"
Which shows that the User-Name is correct.
NAS-Port = 64901 NAS-Port-Type = Wireless-802.11 NAS-IP-Address = 172.18.255.6 NAS-Identifier = "Juniper" Message-Authenticator = 0xe3d83b401df09685c4df6a885095fa4f # Executing section authorize from file /etc/raddb/sites-enabled/default +group authorize { ++[preprocess] = ok ++[mschap] = noop ++[digest] = noop [suffix] No '@' in User-Name = "podia-user", looking up realm NULL [suffix] Found realm "NULL" [suffix] Adding Realm = "NULL" [suffix] Authentication realm is LOCAL. ++[suffix] = ok
Something there is re-writing the User-Name to remove the "AD" portion.
Check the configuration of the "suffice" module. Does it have "strip = yes" ?
[eap] EAP packet type response id 1 length 18 [eap] No EAP Start, assuming it's an on-going EAP conversation ++[eap] = updated [files] users: Matched entry DEFAULT at line 50
Does that entry strip the user name?
[eap] Identity (AD\podia-user) does not match User-Name (podia-user).
The User-Name has been re-written from "AD\podia-user" to "podia-user". It doesn't happen by magic. Something has updated it.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
I wouldn't be so sure /etc/etc wasn't updated. Have you gone back to your backup and compared all the files?? If you're not running eap I find the symlink in sites-enabled for inner-tunnel always comes back each time I patch. So I wouldn't be at all surprised if files got over written by updating core packages. If you have custom dictionaries they always seem to get messed up by patching too. On 30/12/2015 6:52 AM, "Migo Pod" <migopod@gmail.com> wrote:
In proxy.conf all of the defined realms have nostrip included, and the only thing I can find that explicitly rewrites anything is a directive in the NULL realm that sets Stripped-User-Name to mschap:User-Name when the User-Name matches a /host\/[^\.].(.+)/ regex, and that's been in there since at least 2013. I've tried removing that clause from the realm and it didn't appear to affect anything. Other than that, I can't find anything that sets User-Name to anything at all.
Of course things changed on the 16th when updates ran, but none of the files in /etc/raddb were modified since yum doesn't overwrite modified files, and the rpm chagnelogs aren't being particularly helpful.
Thanks, -mat
On Tue, Dec 29, 2015 at 10:59 AM, Alan DeKok <aland@deployingradius.com> wrote:
On Dec 29, 2015, at 11:39 AM, Migo Pod <migopod@gmail.com> wrote:
The change would have been whatever changed with yum-update, which ran
on
the 16th, and did include the freeradius, freeradius-utils and freeradius-mysql packages, but according to the RedHat change logs those packages were updated in September to fix the miscalculated MPPE keys with TLS 1.2 and nothing beyond that.
Clearly there was something beyond that.
Full debug: Waking up in 2.6 seconds. rad_recv: Access-Request packet from host 172.18.255.6 port 20002, id=254, length=162 NAS-Port-Id = "AP1306/2" Calling-Station-Id = "6C-88-14-54-69-28" Called-Station-Id = "00-26-3E-8D-79-C1:UWMWiFi" Service-Type = Framed-User EAP-Message = 0x020100120141445c706f6469612d75736572 User-Name = "AD\\podia-user"
Which shows that the User-Name is correct.
NAS-Port = 64901 NAS-Port-Type = Wireless-802.11 NAS-IP-Address = 172.18.255.6 NAS-Identifier = "Juniper" Message-Authenticator = 0xe3d83b401df09685c4df6a885095fa4f # Executing section authorize from file
/etc/raddb/sites-enabled/default
+group authorize { ++[preprocess] = ok ++[mschap] = noop ++[digest] = noop [suffix] No '@' in User-Name = "podia-user", looking up realm NULL [suffix] Found realm "NULL" [suffix] Adding Realm = "NULL" [suffix] Authentication realm is LOCAL. ++[suffix] = ok
Something there is re-writing the User-Name to remove the "AD" portion.
Check the configuration of the "suffice" module. Does it have "strip = yes" ?
[eap] EAP packet type response id 1 length 18 [eap] No EAP Start, assuming it's an on-going EAP conversation ++[eap] = updated [files] users: Matched entry DEFAULT at line 50
Does that entry strip the user name?
[eap] Identity (AD\podia-user) does not match User-Name (podia-user).
The User-Name has been re-written from "AD\podia-user" to "podia-user". It doesn't happen by magic. Something has updated it.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
It did drop some .rpmnew files in raddb, modules and sites-available and
for whatever reason it didn't mess up the custom dictionary this time. I
tried re-symlinking inner-tunnel and default it doesn't appear to be
behaving any differently. The non-rpmnew configuration files haven't
changed recently at all.
Thanks,
-mat
On Tue, Dec 29, 2015 at 12:02 PM, Peter Lambrechtsen <peter@crypt.co.nz>
wrote:
> I wouldn't be so sure /etc/etc wasn't updated.
>
> Have you gone back to your backup and compared all the files??
>
> If you're not running eap I find the symlink in sites-enabled for
> inner-tunnel always comes back each time I patch. So I wouldn't be at all
> surprised if files got over written by updating core packages.
>
> If you have custom dictionaries they always seem to get messed up by
> patching too.
> On 30/12/2015 6:52 AM, "Migo Pod" <migopod@gmail.com> wrote:
>
> > In proxy.conf all of the defined realms have nostrip included, and the
> only
> > thing I can find that explicitly rewrites anything is a directive in the
> > NULL realm that sets Stripped-User-Name to mschap:User-Name when the
> > User-Name matches a /host\/[^\.].(.+)/ regex, and that's been in there
> > since at least 2013. I've tried removing that clause from the realm and
> it
> > didn't appear to affect anything. Other than that, I can't find anything
> > that sets User-Name to anything at all.
> >
> > Of course things changed on the 16th when updates ran, but none of the
> > files in /etc/raddb were modified since yum doesn't overwrite modified
> > files, and the rpm chagnelogs aren't being particularly helpful.
> >
> > Thanks,
> > -mat
> >
> > On Tue, Dec 29, 2015 at 10:59 AM, Alan DeKok <aland@deployingradius.com>
> > wrote:
> >
> > > On Dec 29, 2015, at 11:39 AM, Migo Pod <migopod@gmail.com> wrote:
> > > >
> > > > The change would have been whatever changed with yum-update, which
> ran
> > on
> > > > the 16th, and did include the freeradius, freeradius-utils and
> > > > freeradius-mysql packages, but according to the RedHat change logs
> > those
> > > > packages were updated in September to fix the miscalculated MPPE keys
> > > with
> > > > TLS 1.2 and nothing beyond that.
> > >
> > > Clearly there was something beyond that.
> > >
> > > > Full debug:
> > > > Waking up in 2.6 seconds.
> > > > rad_recv: Access-Request packet from host 172.18.255.6 port 20002,
> > > id=254,
> > > > length=162
> > > > NAS-Port-Id = "AP1306/2"
> > > > Calling-Station-Id = "6C-88-14-54-69-28"
> > > > Called-Station-Id = "00-26-3E-8D-79-C1:UWMWiFi"
> > > > Service-Type = Framed-User
> > > > EAP-Message = 0x020100120141445c706f6469612d75736572
> > > > User-Name = "AD\\podia-user"
> > >
> > > Which shows that the User-Name is correct.
> > >
> > > > NAS-Port = 64901
> > > > NAS-Port-Type = Wireless-802.11
> > > > NAS-IP-Address = 172.18.255.6
> > > > NAS-Identifier = "Juniper"
> > > > Message-Authenticator = 0xe3d83b401df09685c4df6a885095fa4f
> > > > # Executing section authorize from file
> > /etc/raddb/sites-enabled/default
> > > > +group authorize {
> > > > ++[preprocess] = ok
> > > > ++[mschap] = noop
> > > > ++[digest] = noop
> > > > [suffix] No '@' in User-Name = "podia-user", looking up realm NULL
> > > > [suffix] Found realm "NULL"
> > > > [suffix] Adding Realm = "NULL"
> > > > [suffix] Authentication realm is LOCAL.
> > > > ++[suffix] = ok
> > >
> > > Something there is re-writing the User-Name to remove the "AD"
> portion.
> > >
> > > Check the configuration of the "suffice" module. Does it have
> "strip =
> > > yes" ?
> > >
> > > > [eap] EAP packet type response id 1 length 18
> > > > [eap] No EAP Start, assuming it's an on-going EAP conversation
> > > > ++[eap] = updated
> > > > [files] users: Matched entry DEFAULT at line 50
> > >
> > > Does that entry strip the user name?
> > > >
> > > > [eap] Identity (AD\podia-user) does not match User-Name (podia-user).
> > >
> > > The User-Name has been re-written from "AD\podia-user" to
> "podia-user".
> > > It doesn't happen by magic. Something has updated it.
> > >
> > > Alan DeKok.
> > >
> > >
> > > -
> > > List info/subscribe/unsubscribe? See
> > > http://www.freeradius.org/list/users.html
> > >
> > -
> > List info/subscribe/unsubscribe? See
> > http://www.freeradius.org/list/users.html
> -
> List info/subscribe/unsubscribe? See
> http://www.freeradius.org/list/users.html
>
On Dec 29, 2015, at 12:52 PM, Migo Pod <migopod@gmail.com> wrote:
In proxy.conf all of the defined realms have nostrip included, and the only thing I can find that explicitly rewrites anything is a directive in the NULL realm that sets Stripped-User-Name to mschap:User-Name when the User-Name matches a /host\/[^\.].(.+)/ regex,
Uh... you can't put "unlang" directives into a module configuration. Whatever you entered added to the configuration for the NULL real, it does nothing. It never did anything.
and that's been in there since at least 2013. I've tried removing that clause from the realm and it didn't appear to affect anything.
Because it never did anything.
Other than that, I can't find anything that sets User-Name to anything at all.
Of course things changed on the 16th when updates ran, but none of the files in /etc/raddb were modified since yum doesn't overwrite modified files, and the rpm chagnelogs aren't being particularly helpful.
This is what backups are for, TBH. Alan DeKok.
The module configuration stuff was done by the previous admin, and it looks like the same thing is in authorize in inner-tunnel. I'm waiting for /etc/raddb to get recovered from tape so I can diff out the configuration files. Thanks, -mat On Tue, Dec 29, 2015 at 1:13 PM, Alan DeKok <aland@deployingradius.com> wrote:
On Dec 29, 2015, at 12:52 PM, Migo Pod <migopod@gmail.com> wrote:
In proxy.conf all of the defined realms have nostrip included, and the only thing I can find that explicitly rewrites anything is a directive in the NULL realm that sets Stripped-User-Name to mschap:User-Name when the User-Name matches a /host\/[^\.].(.+)/ regex,
Uh... you can't put "unlang" directives into a module configuration.
Whatever you entered added to the configuration for the NULL real, it does nothing. It never did anything.
and that's been in there since at least 2013. I've tried removing that clause from the realm and it didn't appear to affect anything.
Because it never did anything.
Other than that, I can't find anything that sets User-Name to anything at all.
Of course things changed on the 16th when updates ran, but none of the files in /etc/raddb were modified since yum doesn't overwrite modified files, and the rpm chagnelogs aren't being particularly helpful.
This is what backups are for, TBH.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
participants (3)
-
Alan DeKok -
Migo Pod -
Peter Lambrechtsen