On 05/13/2015 03:01 PM, Bahmer, Eric Vaughn wrote:
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.
There is a bit too much complexity to digest in one mail.
It would be beneficial to have a diagram and comments around it to try
to understand your environment and goals.
The only other comment I would make is that trust is not supported in
RHEL6.x it is in tech preview and it is done differently in RHEL7 where
it is supported.
Using 7.1 is recommended.
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
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.
--
Thank you,
Dmitri Pal
Director of Engineering for IdM portfolio
Red Hat, Inc.
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project
