<div dir="ltr"><div>After further testing, I've discovered that the dev system wasn't working as well as I thought it was: HBAC and sshd don't seem to be playing well together on one server, but fine on the other?<br><br></div>ie, I can run the same commands from both ipa-server and ipa-client:<br><br>ipa hbactest --user=user1 --host=<a href="http://ipa-server.unixdev.petermac.org.au">ipa-server.unixdev.petermac.org.au</a> --service=sshd<br>ipa hbactest --user=user1 --host=<a href="http://ipa-client.unixdev.petermac.org.au">ipa-client.unixdev.petermac.org.au</a> --service=sshd<br><div><br><br></div><div>and every response is:<br><br></div><div>to the ipa-client<br></div><div>--------------------<br>Access granted: True<br>--------------------<br> Matched rules: Admin Users (w sudo)<br> Matched rules: Users<br><br></div><div>to the ipa-server<br>--------------------<br>Access granted: True<br>--------------------<br> Matched rules: Cluster Admin Users (sudo)<br> Not matched rules: Cluster Users<br><br><br></div><div>but when I try to login to the ipa-server, I get an instance disconnect? I can login happily to the ipa-client no problems.<br><br></div><div>Is there a special rule about sshd and the ipa-server?<br><br></div><div>cheers<br></div><div>L.<br></div><div><br></div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>------<br>The most dangerous phrase in the language is, "We've always done it this way."<br><br>- Grace Hopper<br></div></div></div></div> <br><div class="gmail_quote">On 11 October 2016 at 14:06, Lachlan Musicman <span dir="ltr"><<a href="mailto:datakid@gmail.com" target="_blank">datakid@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>Hola,<br><br></div>I've set up a test domain that's as much as possible the same as the prod domain, and successfully got a one way trust against the AD: cantos 7.2, ipa 4.2.0-15/api2.156, sssd (copr) 1.14.1-3<br><br></div>On that test domain I believe I have HBAC working successfully.<br><div><div><div><br></div><div>Once I could show that it was working successfully on the test domain we updated all the clients in the prod domain to sssd 1.14.1-3, updated the IPA server, ran ipa-server-upgrade and we disabled "allow all" in the HBAC.<br><br></div><div>And it doesn't work? Two users could login, but none of the others could, and the sudo rules weren't applied in so much as the one user that could login but shouldn't have had sudo, did.<br><br></div><div>I tried stopping sssd/clearing cache/start sssd/waiting; and stopping sssd/deleting /var/lib/sss/db/* /start sssd/waiting.<br><br></div><div>Neither of those worked, so I enabled allow all again.<br><br></div><div>Now I have a bunch of log files to look through, but no clear indication of what might have gone wrong from a quick read. <br></div><div><br></div><div>I can see in the logs where one person is ok'd by HBAC for sshd and another two are denied - when they should have all been ok'd. And I can infer that the reasoning is that HBAC has declared person2 + person3 to not be in a group they most definitely are in from the error messages. But there is no indication of why sssd hasn't properly picked up that person2 is in the correct group?<br></div><div></div><div><br></div><div>I guess the question is, where do I start fixing this? Which logs should I be reading? <br><br>What can I compare between the two set ups (dev and prod) that might give me insight, given that they are largely set up identically?<br><br></div><div>Cheers<br></div><div>L.<br></div><div></div><div><br></div><div><br><br clear="all"><div><div class="m_-9061231902125065838gmail_signature"><div dir="ltr"><div>------<br>The most dangerous phrase in the language is, "We've always done it this way."<br><br>- Grace Hopper<br></div></div></div></div> </div></div></div></div> </blockquote></div><br></div>