<div class="gmail_quote">On Wed, Jul 10, 2013 at 2:07 AM, Jakub Hrozek <<a href="mailto:jhrozek@redhat.com" target="_blank">jhrozek@redhat.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class="im">On Tue, Jul 09, 2013 at 06:43:55PM -0400, Dmitri Pal wrote: > On 07/09/2013 06:01 PM, KodaK wrote: > > > > > > On Tue, Jul 9, 2013 at 4:27 PM, Dmitri Pal <<a href="mailto:dpal@redhat.com">dpal@redhat.com</a> </div><div class="im">> > <mailto:<a href="mailto:dpal@redhat.com">dpal@redhat.com</a>>> wrote: > > > > On 07/09/2013 03:57 PM, KodaK wrote: > >> > >> > >> On Mon, Jul 8, 2013 at 12:50 PM, Rob Crittenden </div><div><div class="h5">> >> <<a href="mailto:rcritten@redhat.com">rcritten@redhat.com</a> <mailto:<a href="mailto:rcritten@redhat.com">rcritten@redhat.com</a>>> wrote: > >> > >> > >> HBAC is enforced by sssd, so no sssd, no HBAC. > >> > >> I think you need to use pam_access to limit users in AIX. > >> > >> > >> I have some work-arounds now, but I'd like to find a way to > >> automate them. What > >> I need is a way to ask IPA "who is allowed to access this > >> particular server?" > >> > >> The goal is go just get a list of allowed users, then there are > >> various mechanisms > >> I can employ to allow access to only the listed users. I plan to > >> do this from the > >> puppet master so I can push the configs from there. I have > >> ipa-admintools and > >> openldap-clients installed on the puppet master. > >> > >> Right now I'm iterating through all the hbacrules and grepping > >> for the server in > >> question, then getting the details of that rule. This is a lot > >> of requests. > > > > > > A valid RFE I would say... > > May be it should be an enhancement for the hbac-test tool? > > However getting a list of the users verbatim is probably costly too. > > May be it would make sense for you to create a group of AIX users > > in IPA and then fetch it from the puppet master traverse its > > memberOf attribute for list of members? > > It will not use HBAC but still would provide some access control > > optimization. > > Will that solve the problem for you? > > > > > > I thought about that, but there are some drawbacks. I don't have "a" > > group of AIX users that access all AIX machines. I have a bunch of > > different AIX machines with different user sets. I can create a group > > for each host called hostname_access -- but then I'm just replicating > > (quite inefficently) information that already exists in the HBAC > > rules. I can probably create one rule per host in HBAC and query that > > particular rule for the allowed users, but this loses the benefit of > > being able to use host and user groups. This is probably where we'll > > end up, though, since it's the least-effort-to-implement (if worst to > > maintain) option. > > > > How does sssd determine if a user is allowed access? Another option > > may be to replicate that functionality in a program or script on the > > puppet master and have it populate some files once a day or so. > > Alternately we could write a PAM module for AIX that replicates that > > functionality. Right now, though, I have no idea how it's done in > > SSSD (a pointer to where it is in the code would be helpful, even.) > > -- > > The government is going to read our mail anyway, might as well make it > > tough for them. GPG Public key ID: B6A1A7C6 > > SSSD and IPA share the same library. > I do not remember the name of it but it takes input: user, host, service > and determines whether user is allowed or not. > It is written in C. So it probably can be ported to AIX. > </div></div>The library that evaluates the rules comes from sssd and is called libipa_hbac. I actually wanted to implement the same couple of months ago to run on my NAS (which can't realistically run SSSD) at home: <a href="https://github.com/jhrozek/pam_hbac" target="_blank">https://github.com/jhrozek/pam_hbac</a> It's not complete but perhaps it's a start. </blockquote></div> <div>Thanks, Jakub, I'll take a look.</div><div> </div>-- The government is going to read our mail anyway, might as well make it tough for them. GPG Public key ID: B6A1A7C6