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

[Bahmer, Eric Vaughn]

I¹ll have to look into the the ports on the idm server then, I¹m not
overly familiar with firewalld, I tried to install iptables and use the
rules I had before I rebuilt the box as RHEL7.1 from RHEL6.6 to test.
But it wouldn¹t take, so I ended up turning firewalld off during testing
since it was behind the other firewall/gateway server.
It probably is using UDP for the connections then, I know you can set an
option in kerberos to use tcp depending on the packet size, but it still
falls back to udp if the attempt fails.

The hardware token radius varies on response time depending on which
configuration I¹m using on the firewall/gateway machine.
If I had them unblock me at the institutional side I can proxy my radius
off their radius and the config is identical to another sub-network that
works fairly quick, couple seconds at most.
The other config uses ldap and takes several seconds since it has to first
open the connection, start tls, pass the root certificate, authenticate as
the top level for the realm, fetch user information, then rebind as the
user with the token.
I have not yet tried to use ldap just for the accounting section in my
radius with kerberos as the auth mechanism on their side since I¹d
probably have to request a radius principal for the firewall/gateway
server since I don¹t own the intranet realm, but I expect it to be nearly
as slow having to take so many extra steps.

I will give setting up firewalld a go then to restrict udp.



Since you mentioned that a cross-realm trust is probably better in this
case (I could always go back to using ipa-3.x on RHEL6), assuming the
following:

Some names changed to protect the guilty.
Vlans 4-windows, 5-nfs (though I can use for some general traffic as
well), 6-management
This is to keep certain types of traffic isolated by vlan and restrict
user access.
Internal networks mostly use 10.vlan.switch.x and are not registered with
the institutional kdc.

Intranet realm: example.gov (in lowercase unfortunately)
My firewall server:   mon-gate1.example.gov   ‹ external network, internal
vlans 5/6
My internal idm: idm2.manage.monitor.net   ‹ vlans 4,5,6 full ipa-server
realm is MANAGE.MONITOR.NET owns domain manage.monitor.net on vlan 6 and
also serves dns for monitor.net on vlan5, I needed a bare-metal dns on the
management vlan for vm host machines.
My windows ad: mon-ad.windows.monitor.net ‹ vlans 4,5,6, owns domain
windows.monitor.net on vlan4 and is a vm.
I already have a trust between manage.monitor.net and windows.monitor.net,
but not the groups or account mapping since I need consistent uid/gid.
I¹m assuming I need to set up a kdc on the firewall/gateway
mon-gate1.example.gov, and have idm trust that, or both idm and the ad
trust it, but have the kdc on the firewall/gateway trust the example.gov
intranet realm.
The only place I¹m confused is how to set up the kdc on the gateway as
it¹s multi-homed, I¹m assuming it needs to use it¹s own intranet
resolvable fqdn but with a different realm name like BRIDGE.MONITOR.NET or
something and make sure that krb5.conf indicates that
mon-gate1.example.gov is part of the realm.


How I get it done isn¹t quite as important is that I can use our hardware
token behind the gateway as I¹m required, for security reasons.


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.