On Thu, 2015-06-04 at 21:48 +0000, Bahmer, Eric Vaughn wrote: > 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? >
Anything is possible. What you need to do is capture the incoming krb5 traffic and the outgoing RADIUS traffic from the KDC. The question you need to answer from this data is: does the two output RADIUS requests correspond to one or two incoming krb5 requests. If there are two krb5 requests, then there is probably a bug in SSSD. If there is only one krb5 request, then there is probably a bug or configuration issue in the krb5-otp plugin. Nathaniel > 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
