[Freeipa-users] ipa spamming radius with otp token?

[Bahmer, Eric Vaughn]

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
88.
I have restricted the service to the specific interface via zone and rich
rule.


……..
<zone>
    <interface name=“bond0”/>
….
    <rule family=“ipv4”>
        <source address=“10.6.0.0/24”/>
        <service name=“kerberos”/>
        <log prefix=“firewall-kerberos: “ level=“info”>
            <limit value=“10/m”/>
        </log>
        <accept/>
    </rule>
…..
</zone>

Same for kpasswd on port 464.

I’m also made sure that the krb5.conf has a line for udp_preference_limit
= 1

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
itself.

I’ve managed to get things down to just 2 copies with maybe 1 second
difference:

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[15103]: check pass; user unknown
May 15 15:23:03 idm2 unix_chkpwd[15103]: password check failed for user
(bahmer)
May 15 15:23:03 idm2 sshd[15101]: pam_unix(sshd:auth): authentication
failure; logname= uid=0 euid=0 tty=ssh ruser=
rhost=gate1.manage.monitor.net  user=bahmer
May 15 15:23:07 idm2 sshd[15101]: pam_sss(sshd:auth): authentication
failure; logname= uid=0 euid=0 tty=ssh ruser=
rhost=gate1.manage.monitor.net  user=bahmer
May 15 15:23:07 idm2 sshd[15101]: pam_sss(sshd:auth): received for user
bahmer: 17 (Failure setting user credentials)
May 15 15:23:09 idm2 sshd[15101]: 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
real auth?


>
>On 5/13/15, 12:00 PM, "Nathaniel McCallum" <npmccallum at 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
>>> blacklisted.
>>> 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
>>> that.
>>> 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.
>>
>>Nathaniel
>>
>>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
>>kinit.
>