Someone higher up decided that there was no time for me to resolve this
and I’ve been forced to implement a different method for now.
I can still continue to work on this, I'll just need to find different
hardware to troubleshoot with.
I have set up a kerberos.xml in /etc/firewalld/services restricting to tcp
I have restricted the service to the specific interface via zone and rich
<log prefix=“firewall-kerberos: “ level=“info”>
Same for kpasswd on port 464.
I’m also made sure that the krb5.conf has a line for udp_preference_limit
I’ve also made sure to turn caching off in sssd.conf and restarted that.
I set a 30 second timeout and 0 retries.
Attempting to SSH from the firewall/gateway as a user to the idm server
I’ve managed to get things down to just 2 copies with maybe 1 second
Fri May 15 15:23:05
Packet-Type = Access-Request
NAS-Identifier = “idm2.manage.monitor.net”
Service-Type = Authenticate-Only
User-Name = “bahmer”
User-Password = “123-4567"
On the Idm server /var/log/secure:
May 15 15:23:03 idm2 unix_chkpwd: check pass; user unknown
May 15 15:23:03 idm2 unix_chkpwd: password check failed for user
May 15 15:23:03 idm2 sshd: pam_unix(sshd:auth): authentication
failure; logname= uid=0 euid=0 tty=ssh ruser=
May 15 15:23:07 idm2 sshd: pam_sss(sshd:auth): authentication
failure; logname= uid=0 euid=0 tty=ssh ruser=
May 15 15:23:07 idm2 sshd: pam_sss(sshd:auth): received for user
bahmer: 17 (Failure setting user credentials)
May 15 15:23:09 idm2 sshd: Failed password for bahmer from
10.6.0.41 port 44347 ssh2
I’ve collected some tcpdump information, most of the kerberos traffic is
on the loopback interface and nothing stands out.
I can see the two requests in the tcpdump on the interface the idm server
should be using to talk to radius.
I probably need permission in order to send the captures after sanitizing
them for security policy reasons.
Is it possible that sssd is the culprit trying to do a pre-auth before the
>On 5/13/15, 12:00 PM, "Nathaniel McCallum" <npmccal...@redhat.com> wrote:
>>On Wed, 2015-05-13 at 14:44 +0000, Bahmer, Eric Vaughn wrote:
>>> Institutionally we have a hardware token set up, you use a pin to
>>> unlock the device and it spits out a passcode.
>>> The passcode allows access through kerberos, radius, or ldap binds
>>> to linux servers, or with a custom apache module to websites.
>>> I have an out-of-band private network set up that attaches to our
>>> intranet using a firewall/gateway server which does some port
>>> forwarding for various things like SSH, RDP.
>>> I¹m attempting to set up RADIUS on this firewall/gateway to be used
>>> as a proxy for freeipa to our token system which I¹d like to be able
>>> to use behind the firewall.
>>> However I seem to be getting nearly a dozen requests into the radius
>>> server, about half are dropped as duplicate, but usually 3-6 get
>>> through and since it¹s a single use token the first attempt
>>> succeeds, but the rest fail and cause the hardware token to be
>>> Is there a way to specify that the user radius login is a one-time
>>> token or is this something that sssd or pam is causing?
>>> Or does the OTP support just not work in the way I need it to?
>>> I have this issue with both the inbox 4.1.0 in RHEL7.1 or the
>>> upstream 4.1.4 rpms.
>>> My only alternative is probably to set up a KDC on the firewall to
>>> trust the institutional realm and have the IdM kerberos realm trust
>>> This is also a mixed linux/windows environment behind the firewall,
>>> I¹ve enabled unix attributes in my AD and I¹m using a script to sync
>>> uid/gid with the external ldap.
>>I do think a cross realm trust is the right way to set this up.
>>However, let's look more closely at the RADIUS issue.
>>First, I want to ensure that you are using TCP for your kerberos
>>connections. If you are using UDP for kerberos, then the kerberos
>>client will send a new packet which will cause the KDC to fire off a
>>new set of RADIUS messages. The use of TCP should be enforced with
>>kerberos when using OTP.
>>How long does it take for the hardware token RADIUS server to respond?
>>Have you tried adjusting the number of retries and timeout for the
>>RADIUS server in FreeIPA? A longer timeout or fewer retries will
>>reduce the number of packets transmitted.
>>If you are able to setup a test user with fake credentials and could
>>perform a packet capture of kerberos and RADIUS traffic it would help
>>me understand what is going on here.
>>PS - If I had to take a guess based on what I know now, I would
>>suspect that the real culprit is kinit sending too many requests. This
>>is based on your statement that the RADIUS server is dropping *some*
>>duplicates. This means that the other RADIUS packets are *not*
>>duplicates and probably represent a subsequent AS-REQ on the KDC from
Manage your subscription for the Freeipa-users mailing list:
Go to http://freeipa.org for more info on the project