Oliver Burtchen wrote:
Am Montag, 3. Mai 2010 09:14:26 schrieb Sumit Bose:
On Sun, May 02, 2010 at 08:41:14PM +0200, Oliver Burtchen wrote:
Am Sonntag, 2. Mai 2010 04:43:22 schrieb Rob Crittenden:
Oliver Burtchen wrote:
Hi Stephen,
I nailed the problem now a little bit down. I think it's HBAC with
it's empty rules in the standard configuration. For me it was hard to
recognize that it prevents every user added with "ipa user-add" from
logging in the server or joined machines (via ssh or console). When I
do a "ipa-client-install --on- master --permit" everthing works fine.
Without the "--permit" I always get a access denied via
pam-configuration.
Are there any documentations ready for reading/review for HBAC with
freeipa? At least it would be nice to have some short docu what is
necessary. Could you lead me a little bit?
You need at least sssd 1.1.1 for hbac to work. I just added a tiny bit
of documentation on this yesterday at
http://freeipa.org/page/CLI_Overview#hbac
It might point you in the right direction anyway. I hope to have more
thorough documentation on it available soon.
Thanks for the hint. Just for the record, here are some more
Informations:
http://freeipa.org/page/Concepts_and_Objects#Host_Based_Access_Control
Even more information can be found here:
http://freeipa.org/page/DS_Design_Summary#HBAC_object
This page is basically what I used to implement the IPA HBAC rules in
sssd.
This was exactly the information I needed. Thanks! Also for the examples
below.
I was completely unaware or rather had no clue what the (srchost/host/user)
category options are for. Now I got it and it works.
One other cosmetic thing I observed: There are
hbac-add, hbac-add-host, hbac-add-user, ...
but
hbac-del
and
hbac-remove-host, hbac-remove-user, ...
IMHO it would be more consistent to rename the hbac-remove-* commands
to hbac-del-*
I don't think the current commands are confusing, I may be biased though.
So, at least one more question: ;-)
What are the exact service-names to use in --service? I know basically they
are the ones like in /etc/services, or what pam uses. But I noticed that both
ssh and sshd are applicable for ssh. Is there somewhere a list or do they
provide it by their selfs, and I can only make a good guess and try.
To be honest, I'm not sure myself. I'm guessing that sssd has a
mechanism for determining this. I've filed
https://bugzilla.redhat.com/show_bug.cgi?id=588412 to track this question.
Thanks for the feedback.
rob
Best regards,
Oli
The default configuration in hbac uses the model "denied unless
explicitly allowed" which is why all your logins failed. We don't
currently have any default rules set up, I wonder if we should have
some basic ones for demonstration purposes and to sort of bootstrap
things.
Well, I played around a little bit and managed to setup rules to allow
ssh- login. Now I have some more questions:
a) Is it right that I cannot use wildcards or placeholders in the
service- name? I tried "all" and "*", but only explicite naming like
"ssh" or "sshd" works.
If the service is empty every service is allowed.
b) Is it right, that I have to set host and source-host? For me, it
doesn't work if I do not. My first thought was, if it's not set, it
should always match.
Please set the source host category to 'all':
ipa hbac-mod --srchostcat=all YOUR_RULE_NAME
c) Like a), how to set up a rule for all hosts or source-hosts? Do I have
to put them all in a hostgroup? If so, than it would be very handy, if
ipa could manage such group automagically for reference.
There is also a host category and a user category to set:
ipa hbac-mod --hostcat=all YOUR_RULE_NAME
ipa hbac-mod --usercat=all YOUR_RULE_NAME
d) How to setup a rule which restrics services like nfs to the lan (and
known hosts), but permits ssh from every machine over the internet
(unknown hosts)?
You will need two rules one for the service sshd and one for nfs.
e) Like Simo suggested, finally how to setup an explicit permit all rule
for testing?
ipa hbac-add --type=allow allow_all
ipa hbac-mod --srchostcat=all allow_all
ipa hbac-mod --hostcat=all allow_all
ipa hbac-mod --usercat=all allow_all
HTH.
bye,
Sumit
Best regards,
Oli
rob
And thanks for your explanation about the sssd and sssd12 branch/repo
at jdennis. It makes the difference very clear to me and I now use
the sssd12 for testing (just to calm down a little bit ;-) . Maybe
a little readme.txt with your explanation would be quite nice on the
server, so other people don't have to ask again.
Best regards,
Oli
Am Mittwoch, 21. April 2010 22:41:53 schrieb Stephen Gallagher:
On 04/21/2010 02:53 PM, Oliver Burtchen wrote:
Hi Stephen,
thanks for the answer. Yes, I used the ipa-client-install tool. But
I had
first
patched in this fix
https://www.redhat.com/archives/freeipa-devel/2010-April/msg00004.h
tml
from Rob to get 'join' working again. Well, living at the bleeding
edge.
;-)
I'll see if I can nail the problem down.
You may find the debug logs in /var/log/sssd/. At their default
settings (level 0) these logs will display only critical errors. But
if you need more information, you can turn up the debug_level in the
/etc/sssd/sssd.conf file and restart the SSSD. Then your debug logs
will fill up fairly quickly.
Btw., what's the difference between
the sssd and sssd12 repos at jdennis? What is the most recent one,
whats
best
to use with the ipa-devel repo?
We split the development of 1.2 off into it's own branch. Builds
from that branch are put into the sssd12 repo. We're aiming to
release 1.2.0 at the beginning of May. So that's the branch targeted
towards our next public release. We did this so we could put the
finishing touches on SSSD 1.2 while those of us who have completed
their 1.2 tasks can move ahead.
The sssd repo contains our more experimental changes (for example,
the internal cache interface was completely rewritten). These are
the changes that will be forthcoming in sssd 1.3 sometime this
summer.
So your choices are:
sssd12: Stabilizing towards release
sssd: Hang on for dear life(*)
(*) I usually run on this branch - eating my own dogfood, as it were
- though we make no guarantees that it won't break.
_______________________________________________
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
_______________________________________________
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
_______________________________________________
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
