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