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

On that test domain I believe I have HBAC working successfully.

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.

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.

I tried stopping sssd/clearing cache/start sssd/waiting; and stopping
sssd/deleting /var/lib/sss/db/* /start sssd/waiting.

Neither of those worked, so I enabled allow all again.

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.

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?

I guess the question is, where do I start fixing this? Which logs should I
be reading?

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?


The most dangerous phrase in the language is, "We've always done it this

- Grace Hopper
Manage your subscription for the Freeipa-users mailing list:
Go to http://freeipa.org for more info on the project

Reply via email to