From o.burtchen at gmx.de Sun May 2 01:34:55 2010 From: o.burtchen at gmx.de (Oliver Burtchen) Date: Sun, 2 May 2010 03:34:55 +0200 Subject: [Freeipa-users] Is sssd currently useable with freeipa v2 ? In-Reply-To: <4BCF6311.5030902@redhat.com> References: <201004211934.54063.o.burtchen@gmx.de> <201004212053.10969.o.burtchen@gmx.de> <4BCF6311.5030902@redhat.com> Message-ID: <201005020334.55464.o.burtchen@gmx.de> 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? 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.html > > > > 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 at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > -- Oliver Burtchen, Berlin From rcritten at redhat.com Sun May 2 02:43:22 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Sat, 01 May 2010 22:43:22 -0400 Subject: [Freeipa-users] Is sssd currently useable with freeipa v2 ? In-Reply-To: <201005020334.55464.o.burtchen@gmx.de> References: <201004211934.54063.o.burtchen@gmx.de> <201004212053.10969.o.burtchen@gmx.de> <4BCF6311.5030902@redhat.com> <201005020334.55464.o.burtchen@gmx.de> Message-ID: <4BDCE6CA.8060904@redhat.com> 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. 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. 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.html >>> >>> 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 at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users >> > From ssorce at redhat.com Sun May 2 15:56:15 2010 From: ssorce at redhat.com (Simo Sorce) Date: Sun, 2 May 2010 11:56:15 -0400 Subject: [Freeipa-users] Is sssd currently useable with freeipa v2 ? In-Reply-To: <4BDCE6CA.8060904@redhat.com> References: <201004211934.54063.o.burtchen@gmx.de> <201004212053.10969.o.burtchen@gmx.de> <4BCF6311.5030902@redhat.com> <201005020334.55464.o.burtchen@gmx.de> <4BDCE6CA.8060904@redhat.com> Message-ID: <20100502115615.30db626a@willson.li.ssimo.org> On Sat, 01 May 2010 22:43:22 -0400 Rob Crittenden wrote: > 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. I think we should have a default *explicit* permit all rule that admins will promptly remove as soon as they have decided what is their final configuration. Otherwise it will make things too nasty for people that are setting it up for the first time. Simo. -- Simo Sorce * Red Hat, Inc * New York From o.burtchen at gmx.de Sun May 2 18:41:14 2010 From: o.burtchen at gmx.de (Oliver Burtchen) Date: Sun, 2 May 2010 20:41:14 +0200 Subject: [Freeipa-users] Is sssd currently useable with freeipa v2 ? In-Reply-To: <4BDCE6CA.8060904@redhat.com> References: <201004211934.54063.o.burtchen@gmx.de> <201005020334.55464.o.burtchen@gmx.de> <4BDCE6CA.8060904@redhat.com> Message-ID: <201005022041.14824.o.burtchen@gmx.de> 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 > > 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. 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. 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. 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)? e) Like Simo suggested, finally how to setup an explicit permit all rule for testing? 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.html > >>> > >>> 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 at redhat.com > >> https://www.redhat.com/mailman/listinfo/freeipa-users > -- Oliver Burtchen, Berlin From sbose at redhat.com Mon May 3 07:14:26 2010 From: sbose at redhat.com (Sumit Bose) Date: Mon, 3 May 2010 09:14:26 +0200 Subject: [Freeipa-users] Is sssd currently useable with freeipa v2 ? In-Reply-To: <201005022041.14824.o.burtchen@gmx.de> References: <201004211934.54063.o.burtchen@gmx.de> <201005020334.55464.o.burtchen@gmx.de> <4BDCE6CA.8060904@redhat.com> <201005022041.14824.o.burtchen@gmx.de> Message-ID: <20100503071426.GB18583@localhost.localdomain> 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. > > > > > 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.html > > >>> > > >>> 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 at redhat.com > > >> https://www.redhat.com/mailman/listinfo/freeipa-users > > > > -- > Oliver Burtchen, Berlin > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From rcritten at redhat.com Mon May 3 13:35:43 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 03 May 2010 09:35:43 -0400 Subject: [Freeipa-users] ERROR: unable to set Cipher List In-Reply-To: <201005010033.38299.o.burtchen@gmx.de> References: <201005010033.38299.o.burtchen@gmx.de> Message-ID: <4BDED12F.3090401@redhat.com> Oliver Burtchen wrote: > Hi @all, > > I did a clean, minimum F-12 install with all updates, and used freeipa and > sssd12 from http://jdennis.fedorapeople.org/ > > Everything seems to work fine when I do a > > ipa-server-install --setup-dns > > But what does it mean what I see in ipaserver-install.log (attached)? Is this > hamfull, or just a missing, unused cipher-library? Or missing dependency when > installing? As I said, pki-ca, dogtag and freeipa seem to work. It isn't harmful though it is a bit alarming and annoying. I filed a bug against dogtag for this issue: https://bugzilla.redhat.com/show_bug.cgi?id=588323 rob > > Best regards and thanks for answers, > Oli > > > > --- snip --- > Attempting to connect to: test.example.com:9445 > ERROR: unable to set Cipher List > ERROR: Exception = org.mozilla.jss.ssl.SSLSocketException: Failed to enable > cipher 0xc001 > : (-12266) An unknown SSL cipher suite has been requested. > in TestCertApprovalCallback.approve() > Peer cert details: > subject: CN=test.example.com,O=2010-04-30 23:48:30 > issuer: CN=test.example.com,O=2010-04-30 23:48:30 > serial: 0 > item 1 reason=-8156 depth=1 > cert details: > subject: CN=test.example.com,O=2010-04-30 23:48:30 > issuer: CN=test.example.com,O=2010-04-30 23:48:30 > serial: 0 > item 2 reason=-8172 depth=1 > cert details: > subject: CN=test.example.com,O=2010-04-30 23:48:30 > issuer: CN=test.example.com,O=2010-04-30 23:48:30 > serial: 0 > importing certificate. > Connected. > Posting Query = > https://test.example.com:9445//ca/admin/console/config/login?pin=jJMsl21Np7mk6aHPOzm0&xml=true > RESPONSE STATUS: HTTP/1.1 302 Moved Temporarily > RESPONSE HEADER: Server: Apache-Coyote/1.1 > RESPONSE HEADER: Set-Cookie: JSESSIONID=BED7F647B4BFC9FC8BD9F7BCA4A5BF92; > Path=/ca; Secure > RESPONSE HEADER: Location: > https://test.example.com:9445/ca/admin/console/config/wizard > RESPONSE HEADER: Content-Type: text/html;charset=UTF-8 > RESPONSE HEADER: Content-Length: 0 > RESPONSE HEADER: Date: Fri, 30 Apr 2010 21:51:43 GMT > RESPONSE HEADER: Connection: keep-alive > xml returned: > cookie list: JSESSIONID=BED7F647B4BFC9FC8BD9F7BCA4A5BF92; Path=/ca; Secure > --- snip --- > From o.burtchen at gmx.de Mon May 3 14:52:52 2010 From: o.burtchen at gmx.de (Oliver Burtchen) Date: Mon, 3 May 2010 16:52:52 +0200 Subject: [Freeipa-users] Is sssd currently useable with freeipa v2 ? In-Reply-To: <20100503071426.GB18583@localhost.localdomain> References: <201004211934.54063.o.burtchen@gmx.de> <201005022041.14824.o.burtchen@gmx.de> <20100503071426.GB18583@localhost.localdomain> Message-ID: <201005031652.52155.o.burtchen@gmx.de> 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-* 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. 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 at redhat.com > > > >> https://www.redhat.com/mailman/listinfo/freeipa-users > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > -- Oliver Burtchen, Berlin From marc.schlinger at agorabox.org Mon May 3 14:17:18 2010 From: marc.schlinger at agorabox.org (Marc Schlinger) Date: Mon, 03 May 2010 16:17:18 +0200 Subject: [Freeipa-users] Reports and questions Message-ID: <4BDEDAEE.5090203@agorabox.org> Hello, I tried to install freeipa with certs management. I did manage after a problem. 1?) The installation was unable to finished on a french localized system. The error at stage [3/15]: configuring certificate server instance was something like java.utils.MissingResourceException can't find bundle for base name LogMessages, locale fr_FR.UTF-8 full log at then end It's a dogtag error but since I had it while installing freeipa, I report it to you. Finally, for the installation i used a fresh fedora 12 with en_US.UTF-8 locales, rpms version was 1.9.0GIT3620135-0.fc12, and I activate the testing repos as advised in this thread: [Freeipa-users] call implemented methods via xml-rpc. I tried to play a little with certificates mostly to replace puppet certificate management by the freeipa ones 2?) I wasn't able to do a ipa cert-request --principal=my/test.domain.com my.csr I had this error: ipa: ERROR: Certificate operation cannot be completed: Failure decoding Certificate Signing Request It seems that it was a forgetten line in ipalib/pkcs10.py here's the patch: --- /tmp/pkcs10.py 2010-05-03 16:02:22.929018799 +0200 +++ ipalib/pkcs10.py 2010-05-03 16:02:09.855940583 +0200 @@ -52,6 +52,7 @@ namedtype.NamedType('universalString', char.UniversalString().subtype(subtypeSpec=constraint.ValueSizeConstraint(1, MAX))), namedtype.NamedType('utf8String', char.UTF8String().subtype(subtypeSpec=constraint.ValueSizeConstraint(1, MAX))), namedtype.NamedType('bmpString', char.BMPString().subtype(subtypeSpec=constraint.ValueSizeConstraint(1, MAX))), + namedtype.NamedType('ia5string', char.IA5String().subtype(subtypeSpec=constraint.ValueSizeConstraint(1, MAX))), ) that's all for the report, now I have a question: Is/Will freeipa integrate smart token authentication? In this page : http://freeipa.org/page/Certificate_Management You said that "There is no requirement to provision user certificates.". Smart key authentication require user certificates. # File /var/log/pki-ca/catalina.out 28 avr. 2010 16:08:53 org.apache.catalina.core.ApplicationContext log GRAVE: StandardWrapper.Throwable java.util.MissingResourceException: Can't find bundle for base name LogMessages, locale fr_FR at java.util.ResourceBundle.throwMissingResourceException(ResourceBundle.java:1539) at java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:1278) at java.util.ResourceBundle.getBundle(ResourceBundle.java:733) at com.netscape.cmscore.apps.CMSEngine.getLogMessage(CMSEngine.java:1103) at com.netscape.cmscore.apps.CMSEngine.getLogMessage(CMSEngine.java:1176) at com.netscape.certsrv.apps.CMS.getLogMessage(CMS.java:637) at com.netscape.cms.servlet.common.Utils.initializeAuthz(Utils.java:89) at com.netscape.cms.servlet.base.CMSServlet.init(CMSServlet.java:288) at com.netscape.cms.servlet.csadmin.GetStatus.init(GetStatus.java:61) at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1139) at org.apache.catalina.core.StandardWrapper.allocate(StandardWrapper.java:791) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:127) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:172) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:548) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:108) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:174) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:875) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:665) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:528) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:81) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:689) at java.lang.Thread.run(Thread.java:636) 28 avr. 2010 16:08:53 org.apache.catalina.core.StandardWrapperValve invoke GRAVE: Exception lors de l'allocation pour la servlet caGetStatus java.util.MissingResourceException: Can't find bundle for base name LogMessages, locale fr_FR at java.util.ResourceBundle.throwMissingResourceException(ResourceBundle.java:1539) at java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:1278) at java.util.ResourceBundle.getBundle(ResourceBundle.java:733) at com.netscape.cmscore.apps.CMSEngine.getLogMessage(CMSEngine.java:1103) at com.netscape.cmscore.apps.CMSEngine.getLogMessage(CMSEngine.java:1176) at com.netscape.certsrv.apps.CMS.getLogMessage(CMS.java:637) at com.netscape.cms.servlet.common.Utils.initializeAuthz(Utils.java:89) at com.netscape.cms.servlet.base.CMSServlet.init(CMSServlet.java:288) at com.netscape.cms.servlet.csadmin.GetStatus.init(GetStatus.java:61) at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1139) at org.apache.catalina.core.StandardWrapper.allocate(StandardWrapper.java:791) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:127) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:172) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:548) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:108) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:174) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:875) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:665) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:528) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:528) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:81) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:689) at java.lang.Thread.run(Thread.java:636) [Fatal Error] :1:8: The string "--" is not permitted within comments. 28 avr. 2010 16:08:58 org.apache.catalina.core.ApplicationContext log GRAVE: StandardWrapper.Throwable java.util.MissingResourceException: Can't find bundle for base name LogMessages, locale fr_FR at java.util.ResourceBundle.throwMissingResourceException(ResourceBundle.java:1539) at java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:1278) at java.util.ResourceBundle.getBundle(ResourceBundle.java:733) at com.netscape.cmscore.apps.CMSEngine.getLogMessage(CMSEngine.java:1103) at com.netscape.cmscore.apps.CMSEngine.getLogMessage(CMSEngine.java:1176) at com.netscape.certsrv.apps.CMS.getLogMessage(CMS.java:637) at com.netscape.cms.servlet.common.Utils.initializeAuthz(Utils.java:89) at com.netscape.cms.servlet.base.CMSServlet.init(CMSServlet.java:288) at com.netscape.cms.servlet.csadmin.GetStatus.init(GetStatus.java:61) at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1139) at org.apache.catalina.core.StandardWrapper.allocate(StandardWrapper.java:791) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:127) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:172) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:548) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:108) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:174) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:875) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:665) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:528) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:81) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:689) at java.lang.Thread.run(Thread.java:636) 28 avr. 2010 16:08:58 org.apache.catalina.core.StandardWrapperValve invoke GRAVE: Exception lors de l'allocation pour la servlet caGetStatus java.util.MissingResourceException: Can't find bundle for base name LogMessages, locale fr_FR at java.util.ResourceBundle.throwMissingResourceException(ResourceBundle.java:1539) at java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:1278) at java.util.ResourceBundle.getBundle(ResourceBundle.java:733) at com.netscape.cmscore.apps.CMSEngine.getLogMessage(CMSEngine.java:1103) at com.netscape.cmscore.apps.CMSEngine.getLogMessage(CMSEngine.java:1176) at com.netscape.certsrv.apps.CMS.getLogMessage(CMS.java:637) at com.netscape.cms.servlet.common.Utils.initializeAuthz(Utils.java:89) at com.netscape.cms.servlet.base.CMSServlet.init(CMSServlet.java:288) at com.netscape.cms.servlet.csadmin.GetStatus.init(GetStatus.java:61) at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1139) at org.apache.catalina.core.StandardWrapper.allocate(StandardWrapper.java:791) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:127) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:172) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:548) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:108) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:174) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:875) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:665) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:528) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:81) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:689) at java.lang.Thread.run(Thread.java:636) [Fatal Error] :1:8: The string "--" is not permitted within comments. Exception caught: java.io.IOException: The value for preop.cert.signing.type should be remote Exception caught: java.io.IOException: The value for preop.cert.ocsp_signing.type should be remote Exception caught: java.io.IOException: The value for preop.cert.sslserver.type should be remote Exception caught: java.io.IOException: The value for preop.cert.subsystem.type should be remote Exception caught: java.io.IOException: The value for preop.cert.audit_signing.type should be remote From o.burtchen at gmx.de Mon May 3 15:11:33 2010 From: o.burtchen at gmx.de (Oliver Burtchen) Date: Mon, 3 May 2010 17:11:33 +0200 Subject: [Freeipa-users] Reports and questions In-Reply-To: <4BDEDAEE.5090203@agorabox.org> References: <4BDEDAEE.5090203@agorabox.org> Message-ID: <201005031711.33902.o.burtchen@gmx.de> Am Montag, 3. Mai 2010 16:17:18 schrieb Marc Schlinger: > Hello, > > I tried to install freeipa with certs management. I did manage after a > problem. > > 1?) The installation was unable to finished on a french localized system. > The error at stage [3/15]: configuring certificate server instance was > something like > > java.utils.MissingResourceException can't find bundle for base name > LogMessages, locale fr_FR.UTF-8 > full log at then end > > It's a dogtag error but since I had it while installing freeipa, I > report it to you. > This is a bug I also encountered https://bugzilla.redhat.com/show_bug.cgi?id=583177 Quick workaround is to set the system locale (system-config-language) to english just before ipa-server-install, and switch it back to yours after that. Best regards, Oli > Finally, for the installation i used a fresh fedora 12 with en_US.UTF-8 > locales, rpms version was 1.9.0GIT3620135-0.fc12, > and I activate the testing repos as advised in this thread: > [Freeipa-users] call implemented methods via xml-rpc. > > I tried to play a little with certificates mostly to replace puppet > certificate management by the freeipa ones > 2?) I wasn't able to do a ipa cert-request > --principal=my/test.domain.com my.csr > I had this error: > ipa: ERROR: Certificate operation cannot be completed: Failure decoding > Certificate Signing Request > > It seems that it was a forgetten line in ipalib/pkcs10.py > here's the patch: > > --- /tmp/pkcs10.py 2010-05-03 16:02:22.929018799 +0200 > +++ ipalib/pkcs10.py 2010-05-03 16:02:09.855940583 +0200 > @@ -52,6 +52,7 @@ > namedtype.NamedType('universalString', > char.UniversalString().subtype(subtypeSpec=constraint.ValueSizeConstraint(1 > , MAX))), > namedtype.NamedType('utf8String', > char.UTF8String().subtype(subtypeSpec=constraint.ValueSizeConstraint(1, > MAX))), > namedtype.NamedType('bmpString', > char.BMPString().subtype(subtypeSpec=constraint.ValueSizeConstraint(1, > MAX))), > + namedtype.NamedType('ia5string', > char.IA5String().subtype(subtypeSpec=constraint.ValueSizeConstraint(1, > MAX))), > ) > > > > > > that's all for the report, now I have a question: > > Is/Will freeipa integrate smart token authentication? > In this page : http://freeipa.org/page/Certificate_Management > You said that "There is no requirement to provision user certificates.". > Smart key authentication require user certificates. > > > > > > > # File /var/log/pki-ca/catalina.out > 28 avr. 2010 16:08:53 org.apache.catalina.core.ApplicationContext log > GRAVE: StandardWrapper.Throwable > java.util.MissingResourceException: Can't find bundle for base name > LogMessages, locale fr_FR > at > java.util.ResourceBundle.throwMissingResourceException(ResourceBundle.java: > 1539) at java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:1278) > at java.util.ResourceBundle.getBundle(ResourceBundle.java:733) at > com.netscape.cmscore.apps.CMSEngine.getLogMessage(CMSEngine.java:1103) > at > com.netscape.cmscore.apps.CMSEngine.getLogMessage(CMSEngine.java:1176) > at com.netscape.certsrv.apps.CMS.getLogMessage(CMS.java:637) > at > com.netscape.cms.servlet.common.Utils.initializeAuthz(Utils.java:89) > at > com.netscape.cms.servlet.base.CMSServlet.init(CMSServlet.java:288) > at > com.netscape.cms.servlet.csadmin.GetStatus.init(GetStatus.java:61) > at > org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1 > 139) at > org.apache.catalina.core.StandardWrapper.allocate(StandardWrapper.java:791) > at > org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.j > ava:127) at > org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.j > ava:172) at > org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:12 > 7) at > org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:11 > 7) at > org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:548) > at > org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.jav > a:108) at > org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:174) > at > org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:875) > at > org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.process > Connection(Http11BaseProtocol.java:665) at > org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.ja > va:528) at > org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerW > orkerThread.java:81) at > org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.ja > va:689) at java.lang.Thread.run(Thread.java:636) > 28 avr. 2010 16:08:53 org.apache.catalina.core.StandardWrapperValve invoke > GRAVE: Exception lors de l'allocation pour la servlet caGetStatus > java.util.MissingResourceException: Can't find bundle for base name > LogMessages, locale fr_FR > at > java.util.ResourceBundle.throwMissingResourceException(ResourceBundle.java: > 1539) at java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:1278) > at java.util.ResourceBundle.getBundle(ResourceBundle.java:733) at > com.netscape.cmscore.apps.CMSEngine.getLogMessage(CMSEngine.java:1103) > at > com.netscape.cmscore.apps.CMSEngine.getLogMessage(CMSEngine.java:1176) > at com.netscape.certsrv.apps.CMS.getLogMessage(CMS.java:637) > at > com.netscape.cms.servlet.common.Utils.initializeAuthz(Utils.java:89) > at > com.netscape.cms.servlet.base.CMSServlet.init(CMSServlet.java:288) > at > com.netscape.cms.servlet.csadmin.GetStatus.init(GetStatus.java:61) > at > org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1 > 139) at > org.apache.catalina.core.StandardWrapper.allocate(StandardWrapper.java:791) > at > org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.j > ava:127) at > org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.j > ava:172) at > org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:12 > 7) at > org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:11 > 7) at > org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:548) > at > org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.jav > a:108) at > org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:174) > at > org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:875) > at > org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.process > Connection(Http11BaseProtocol.java:665) at > org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.ja > va:528) at > org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.ja > va:528) at > org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerW > orkerThread.java:81) at > org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.ja > va:689) at java.lang.Thread.run(Thread.java:636) > [Fatal Error] :1:8: The string "--" is not permitted within comments. > 28 avr. 2010 16:08:58 org.apache.catalina.core.ApplicationContext log > GRAVE: StandardWrapper.Throwable > java.util.MissingResourceException: Can't find bundle for base name > LogMessages, locale fr_FR > at > java.util.ResourceBundle.throwMissingResourceException(ResourceBundle.java: > 1539) at java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:1278) > at java.util.ResourceBundle.getBundle(ResourceBundle.java:733) at > com.netscape.cmscore.apps.CMSEngine.getLogMessage(CMSEngine.java:1103) > at > com.netscape.cmscore.apps.CMSEngine.getLogMessage(CMSEngine.java:1176) > at com.netscape.certsrv.apps.CMS.getLogMessage(CMS.java:637) > at > com.netscape.cms.servlet.common.Utils.initializeAuthz(Utils.java:89) > at > com.netscape.cms.servlet.base.CMSServlet.init(CMSServlet.java:288) > at > com.netscape.cms.servlet.csadmin.GetStatus.init(GetStatus.java:61) > at > org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1 > 139) at > org.apache.catalina.core.StandardWrapper.allocate(StandardWrapper.java:791) > at > org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.j > ava:127) at > org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.j > ava:172) at > org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:12 > 7) at > org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:11 > 7) at > org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:548) > at > org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.jav > a:108) at > org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:174) > at > org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:875) > at > org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.process > Connection(Http11BaseProtocol.java:665) at > org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.ja > va:528) at > org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerW > orkerThread.java:81) at > org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.ja > va:689) at java.lang.Thread.run(Thread.java:636) > 28 avr. 2010 16:08:58 org.apache.catalina.core.StandardWrapperValve invoke > GRAVE: Exception lors de l'allocation pour la servlet caGetStatus > java.util.MissingResourceException: Can't find bundle for base name > LogMessages, locale fr_FR > at > java.util.ResourceBundle.throwMissingResourceException(ResourceBundle.java: > 1539) at java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:1278) > at java.util.ResourceBundle.getBundle(ResourceBundle.java:733) at > com.netscape.cmscore.apps.CMSEngine.getLogMessage(CMSEngine.java:1103) > at > com.netscape.cmscore.apps.CMSEngine.getLogMessage(CMSEngine.java:1176) > at com.netscape.certsrv.apps.CMS.getLogMessage(CMS.java:637) > at > com.netscape.cms.servlet.common.Utils.initializeAuthz(Utils.java:89) > at > com.netscape.cms.servlet.base.CMSServlet.init(CMSServlet.java:288) > at > com.netscape.cms.servlet.csadmin.GetStatus.init(GetStatus.java:61) > at > org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1 > 139) at > org.apache.catalina.core.StandardWrapper.allocate(StandardWrapper.java:791) > at > org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.j > ava:127) at > org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.j > ava:172) at > org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:12 > 7) at > org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:11 > 7) at > org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:548) > at > org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.jav > a:108) at > org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:174) > at > org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:875) > at > org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.process > Connection(Http11BaseProtocol.java:665) at > org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.ja > va:528) at > org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerW > orkerThread.java:81) at > org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.ja > va:689) at java.lang.Thread.run(Thread.java:636) > [Fatal Error] :1:8: The string "--" is not permitted within comments. > Exception caught: java.io.IOException: The value for > preop.cert.signing.type should be remote > Exception caught: java.io.IOException: The value for > preop.cert.ocsp_signing.type should be remote > Exception caught: java.io.IOException: The value for > preop.cert.sslserver.type should be remote > Exception caught: java.io.IOException: The value for > preop.cert.subsystem.type should be remote > Exception caught: java.io.IOException: The value for > preop.cert.audit_signing.type should be remote > > > > > > > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > -- Oliver Burtchen, Berlin From rcritten at redhat.com Mon May 3 15:38:38 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 03 May 2010 11:38:38 -0400 Subject: [Freeipa-users] Reports and questions In-Reply-To: <4BDEDAEE.5090203@agorabox.org> References: <4BDEDAEE.5090203@agorabox.org> Message-ID: <4BDEEDFE.4020308@redhat.com> Marc Schlinger wrote: > Hello, > > I tried to install freeipa with certs management. I did manage after a > problem. > > 1?) The installation was unable to finished on a french localized system. > The error at stage [3/15]: configuring certificate server instance was > something like > > java.utils.MissingResourceException can't find bundle for base name > LogMessages, locale fr_FR.UTF-8 > full log at then end > > It's a dogtag error but since I had it while installing freeipa, I > report it to you. > > Finally, for the installation i used a fresh fedora 12 with en_US.UTF-8 > locales, rpms version was 1.9.0GIT3620135-0.fc12, > and I activate the testing repos as advised in this thread: > [Freeipa-users] call implemented methods via xml-rpc. Yes, I have this on my list to try to work around. I'm going to set the en_US locale while we're installing dogtag, I just don't know what this will do post-installation, if things will again blow up. I opened a new bug on this against dogtag, https://bugzilla.redhat.com/show_bug.cgi?id=588375 > > I tried to play a little with certificates mostly to replace puppet > certificate management by the freeipa ones > 2?) I wasn't able to do a ipa cert-request > --principal=my/test.domain.com my.csr > I had this error: > ipa: ERROR: Certificate operation cannot be completed: Failure decoding > Certificate Signing Request > > It seems that it was a forgetten line in ipalib/pkcs10.py > here's the patch: > > --- /tmp/pkcs10.py 2010-05-03 16:02:22.929018799 +0200 > +++ ipalib/pkcs10.py 2010-05-03 16:02:09.855940583 +0200 > @@ -52,6 +52,7 @@ > namedtype.NamedType('universalString', > char.UniversalString().subtype(subtypeSpec=constraint.ValueSizeConstraint(1, > MAX))), > namedtype.NamedType('utf8String', > char.UTF8String().subtype(subtypeSpec=constraint.ValueSizeConstraint(1, > MAX))), > namedtype.NamedType('bmpString', > char.BMPString().subtype(subtypeSpec=constraint.ValueSizeConstraint(1, > MAX))), > + namedtype.NamedType('ia5string', > char.IA5String().subtype(subtypeSpec=constraint.ValueSizeConstraint(1, > MAX))), > ) Hmm. The python-pyasn1 x509.py sample has ia5string defined as well but it isn't in RFC 3280 as a supported type for DirectoryString. I can go ahead and add it in. Can you send me a certificate that is not being parsed by the current pkcs10 module? > that's all for the report, now I have a question: > > Is/Will freeipa integrate smart token authentication? > In this page : http://freeipa.org/page/Certificate_Management > You said that "There is no requirement to provision user certificates.". > Smart key authentication require user certificates. We aren't planning on supporting client certificates for v2. We may add support at some point but it hasn't been planned, designed, etc. Since we use dogtag if/when we implement support for client certs then tokens should be part of that. rob From o.burtchen at gmx.de Mon May 3 17:05:03 2010 From: o.burtchen at gmx.de (Oliver Burtchen) Date: Mon, 3 May 2010 19:05:03 +0200 Subject: [Freeipa-users] Remarks about the WebUI Message-ID: <201005031905.03976.o.burtchen@gmx.de> Hi @all, first, I know freeipa v2 and especially the webui is work in progress in an early state. So please tell me if it is not meaningful yet to report things about the webui. What I observed: In the hbac-section, fields for host, srchost und user are completly missing. And the fields for category are left blank, even if setup with the cli. This way, you can easily mess up your rules if you use the webui at all. Best regards, Oli -- Oliver Burtchen, Berlin From marc.schlinger at agorabox.org Mon May 3 16:07:00 2010 From: marc.schlinger at agorabox.org (Marc Schlinger) Date: Mon, 03 May 2010 18:07:00 +0200 Subject: [Freeipa-users] Reports and questions In-Reply-To: <4BDEEDFE.4020308@redhat.com> References: <4BDEDAEE.5090203@agorabox.org> <4BDEEDFE.4020308@redhat.com> Message-ID: <4BDEF4A4.7000909@agorabox.org> Le 03/05/2010 17:38, Rob Crittenden a ?crit : > Marc Schlinger wrote: >> Hello, >> >> I tried to install freeipa with certs management. I did manage after >> a problem. >> >> 1?) The installation was unable to finished on a french localized >> system. >> The error at stage [3/15]: configuring certificate server instance >> was something like >> >> java.utils.MissingResourceException can't find bundle for base name >> LogMessages, locale fr_FR.UTF-8 >> full log at then end >> >> It's a dogtag error but since I had it while installing freeipa, I >> report it to you. >> >> Finally, for the installation i used a fresh fedora 12 with >> en_US.UTF-8 locales, rpms version was 1.9.0GIT3620135-0.fc12, >> and I activate the testing repos as advised in this thread: >> [Freeipa-users] call implemented methods via xml-rpc. > > Yes, I have this on my list to try to work around. I'm going to set > the en_US locale while we're installing dogtag, I just don't know what > this will do post-installation, if things will again blow up. > > I opened a new bug on this against dogtag, > https://bugzilla.redhat.com/show_bug.cgi?id=588375 > >> >> I tried to play a little with certificates mostly to replace puppet >> certificate management by the freeipa ones >> 2?) I wasn't able to do a ipa cert-request >> --principal=my/test.domain.com my.csr >> I had this error: >> ipa: ERROR: Certificate operation cannot be completed: Failure >> decoding Certificate Signing Request >> >> It seems that it was a forgetten line in ipalib/pkcs10.py >> here's the patch: >> >> --- /tmp/pkcs10.py 2010-05-03 16:02:22.929018799 +0200 >> +++ ipalib/pkcs10.py 2010-05-03 16:02:09.855940583 +0200 >> @@ -52,6 +52,7 @@ >> namedtype.NamedType('universalString', >> char.UniversalString().subtype(subtypeSpec=constraint.ValueSizeConstraint(1, >> MAX))), >> namedtype.NamedType('utf8String', >> char.UTF8String().subtype(subtypeSpec=constraint.ValueSizeConstraint(1, >> MAX))), >> namedtype.NamedType('bmpString', >> char.BMPString().subtype(subtypeSpec=constraint.ValueSizeConstraint(1, MAX))), >> >> + namedtype.NamedType('ia5string', >> char.IA5String().subtype(subtypeSpec=constraint.ValueSizeConstraint(1, MAX))), >> >> ) > > Hmm. The python-pyasn1 x509.py sample has ia5string defined as well > but it isn't in RFC 3280 as a supported type for DirectoryString. I > can go ahead and add it in. Can you send me a certificate that is not > being parsed by the current pkcs10 module? > >> that's all for the report, now I have a question: >> >> Is/Will freeipa integrate smart token authenticaurbeion? >> In this page : http://freeipa.org/page/Certificate_Management >> You said that "There is no requirement to provision user >> certificates.". Smart key authentication require user certificates. > > We aren't planning on supporting client certificates for v2. We may > add support at some point but it hasn't been planned, designed, etc. > Since we use dogtag if/when we implement support for client certs then > tokens should be part of that. > > rob Rob, I'am confused, I'm totally wrong. This patch is absolutly useless. the only way to make ipa cert-request going wrong is omitting -newhdr option whith openssl then the header and footer: -----BEGIN CERTIFICATE REQUEST----- MII.... -----END CERTIFICATE REQUEST----- whereas with the newhdr option we have the header and footer like this: -----BEGIN NEW CERTIFICATE REQUEST----- MII.... -----END NEW CERTIFICATE REQUEST----- p.s: I really had problems without the ia5string stuff. I'm not crazy! am I? From rcritten at redhat.com Mon May 3 17:23:20 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 03 May 2010 13:23:20 -0400 Subject: [Freeipa-users] Reports and questions In-Reply-To: <4BDEF4A4.7000909@agorabox.org> References: <4BDEDAEE.5090203@agorabox.org> <4BDEEDFE.4020308@redhat.com> <4BDEF4A4.7000909@agorabox.org> Message-ID: <4BDF0688.1030807@redhat.com> Marc Schlinger wrote: > Le 03/05/2010 17:38, Rob Crittenden a ?crit : >> Marc Schlinger wrote: >>> Hello, >>> >>> I tried to install freeipa with certs management. I did manage after >>> a problem. >>> >>> 1?) The installation was unable to finished on a french localized >>> system. >>> The error at stage [3/15]: configuring certificate server instance >>> was something like >>> >>> java.utils.MissingResourceException can't find bundle for base name >>> LogMessages, locale fr_FR.UTF-8 >>> full log at then end >>> >>> It's a dogtag error but since I had it while installing freeipa, I >>> report it to you. >>> >>> Finally, for the installation i used a fresh fedora 12 with >>> en_US.UTF-8 locales, rpms version was 1.9.0GIT3620135-0.fc12, >>> and I activate the testing repos as advised in this thread: >>> [Freeipa-users] call implemented methods via xml-rpc. >> >> Yes, I have this on my list to try to work around. I'm going to set >> the en_US locale while we're installing dogtag, I just don't know what >> this will do post-installation, if things will again blow up. >> >> I opened a new bug on this against dogtag, >> https://bugzilla.redhat.com/show_bug.cgi?id=588375 >> >>> >>> I tried to play a little with certificates mostly to replace puppet >>> certificate management by the freeipa ones >>> 2?) I wasn't able to do a ipa cert-request >>> --principal=my/test.domain.com my.csr >>> I had this error: >>> ipa: ERROR: Certificate operation cannot be completed: Failure >>> decoding Certificate Signing Request >>> >>> It seems that it was a forgetten line in ipalib/pkcs10.py >>> here's the patch: >>> >>> --- /tmp/pkcs10.py 2010-05-03 16:02:22.929018799 +0200 >>> +++ ipalib/pkcs10.py 2010-05-03 16:02:09.855940583 +0200 >>> @@ -52,6 +52,7 @@ >>> namedtype.NamedType('universalString', >>> char.UniversalString().subtype(subtypeSpec=constraint.ValueSizeConstraint(1, >>> MAX))), >>> namedtype.NamedType('utf8String', >>> char.UTF8String().subtype(subtypeSpec=constraint.ValueSizeConstraint(1, >>> MAX))), >>> namedtype.NamedType('bmpString', >>> char.BMPString().subtype(subtypeSpec=constraint.ValueSizeConstraint(1, >>> MAX))), >>> + namedtype.NamedType('ia5string', >>> char.IA5String().subtype(subtypeSpec=constraint.ValueSizeConstraint(1, >>> MAX))), >>> ) >> >> Hmm. The python-pyasn1 x509.py sample has ia5string defined as well >> but it isn't in RFC 3280 as a supported type for DirectoryString. I >> can go ahead and add it in. Can you send me a certificate that is not >> being parsed by the current pkcs10 module? >> >>> that's all for the report, now I have a question: >>> >>> Is/Will freeipa integrate smart token authenticaurbeion? >>> In this page : http://freeipa.org/page/Certificate_Management >>> You said that "There is no requirement to provision user >>> certificates.". Smart key authentication require user certificates. >> >> We aren't planning on supporting client certificates for v2. We may >> add support at some point but it hasn't been planned, designed, etc. >> Since we use dogtag if/when we implement support for client certs then >> tokens should be part of that. >> >> rob > > Rob, > I'am confused, I'm totally wrong. > This patch is absolutly useless. > > the only way to make ipa cert-request going wrong is omitting -newhdr > option whith openssl then the header and footer: > > -----BEGIN CERTIFICATE REQUEST----- > MII.... > -----END CERTIFICATE REQUEST----- > > whereas with the newhdr option we have the header and footer like this: > -----BEGIN NEW CERTIFICATE REQUEST----- > MII.... > -----END NEW CERTIFICATE REQUEST----- Ok, I thought I handled this, I guess not. > > p.s: I really had problems without the ia5string stuff. I'm not crazy! > am I? I don't think so, I just didn't run into it myself. It could be because you use openssl to create the CSR and I used the NSS tools. Or it could be because your locale is different, or the phase of the moon, who knows :-) The pyasn1 guys have a code comment questioning why ia5string is needed as well: # hm, this should not be here!? XXX If we're going to get requests with ia5strings I'm ok with adding support to the parser. The reason I asked for the cert sample was so I would be able to test the fix end-to-end, and perhaps incorporate it into our test suite. rob From dpal at redhat.com Mon May 3 17:39:08 2010 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 03 May 2010 13:39:08 -0400 Subject: [Freeipa-users] Remarks about the WebUI In-Reply-To: <201005031905.03976.o.burtchen@gmx.de> References: <201005031905.03976.o.burtchen@gmx.de> Message-ID: <4BDF0A3C.10104@redhat.com> Oliver Burtchen wrote: > Hi @all, > > first, I know freeipa v2 and especially the webui is work in progress in an > early state. So please tell me if it is not meaningful yet to report things > about the webui. > > What I observed: > > In the hbac-section, fields for host, srchost und user are completly missing. > And the fields for category are left blank, even if setup with the cli. This > way, you can easily mess up your rules if you use the webui at all. > > Best regards, > Oli > > > It is a bit early to report such issues. -- Thank you, Dmitri Pal Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From jdennis at redhat.com Mon May 3 17:51:06 2010 From: jdennis at redhat.com (John Dennis) Date: Mon, 03 May 2010 13:51:06 -0400 Subject: [Freeipa-users] Reports and questions In-Reply-To: <4BDF0688.1030807@redhat.com> References: <4BDEDAEE.5090203@agorabox.org> <4BDEEDFE.4020308@redhat.com> <4BDEF4A4.7000909@agorabox.org> <4BDF0688.1030807@redhat.com> Message-ID: <4BDF0D0A.70309@redhat.com> On 05/03/2010 01:23 PM, Rob Crittenden wrote: > Marc Schlinger wrote: >> p.s: I really had problems without the ia5string stuff. I'm not crazy! >> am I? > > I don't think so, I just didn't run into it myself. It could be because > you use openssl to create the CSR and I used the NSS tools. Or it could > be because your locale is different, or the phase of the moon, who knows > :-) The pyasn1 guys have a code comment questioning why ia5string is > needed as well: # hm, this should not be here!? XXX If we're going to > get requests with ia5strings I'm ok with adding support to the parser. > > The reason I asked for the cert sample was so I would be able to test > the fix end-to-end, and perhaps incorporate it into our test suite. I would hold off making any fixes to the parser you wrote. I've got an update to python-nss coming soon which fully supports certificate loading, decoding and inspection using NSS entry points. It properly (or so I hope) handles all the variants (which are numerous) including ia5string. We should converge on using NSS for everything, the update will get us a lot closer to that goal. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From rcritten at redhat.com Mon May 3 18:55:33 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 03 May 2010 14:55:33 -0400 Subject: [Freeipa-users] Is sssd currently useable with freeipa v2 ? In-Reply-To: <201005031652.52155.o.burtchen@gmx.de> References: <201004211934.54063.o.burtchen@gmx.de> <201005022041.14824.o.burtchen@gmx.de> <20100503071426.GB18583@localhost.localdomain> <201005031652.52155.o.burtchen@gmx.de> Message-ID: <4BDF1C25.1080503@redhat.com> 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 at redhat.com >>>>>> https://www.redhat.com/mailman/listinfo/freeipa-users >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users >> > From sgallagh at redhat.com Mon May 3 19:11:42 2010 From: sgallagh at redhat.com (Stephen Gallagher) Date: Mon, 03 May 2010 15:11:42 -0400 Subject: [Freeipa-users] Is sssd currently useable with freeipa v2 ? In-Reply-To: <4BDF1C25.1080503@redhat.com> References: <201004211934.54063.o.burtchen@gmx.de> <201005022041.14824.o.burtchen@gmx.de> <20100503071426.GB18583@localhost.localdomain> <201005031652.52155.o.burtchen@gmx.de> <4BDF1C25.1080503@redhat.com> Message-ID: <4BDF1FEE.3090208@redhat.com> On 05/03/2010 02:55 PM, Rob Crittenden wrote: > Oliver Burtchen wrote: >> 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. I'm going to let Sumit comment on the Bugzilla ticket, since he'd know better, but I'm 99% certain that we get this directly from PAM (as in, the application itself provides that data when making a PAM request). Looking at a recent auth I performed on my system, I see the raw PAM data that comes in from (for example) 'su -l' is reported to us as "service: su-l". My assumption is that SSSD's HBAC simply treats that as canonical. -- Stephen Gallagher RHCE 804006346421761 Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ From dpal at redhat.com Mon May 3 19:17:35 2010 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 03 May 2010 15:17:35 -0400 Subject: [Freeipa-users] Is sssd currently useable with freeipa v2 ? In-Reply-To: <4BDF1FEE.3090208@redhat.com> References: <201004211934.54063.o.burtchen@gmx.de> <201005022041.14824.o.burtchen@gmx.de> <20100503071426.GB18583@localhost.localdomain> <201005031652.52155.o.burtchen@gmx.de> <4BDF1C25.1080503@redhat.com> <4BDF1FEE.3090208@redhat.com> Message-ID: <4BDF214F.1000701@redhat.com> Stephen Gallagher wrote: > On 05/03/2010 02:55 PM, Rob Crittenden wrote: >> Oliver Burtchen wrote: >>> 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. > > > I'm going to let Sumit comment on the Bugzilla ticket, since he'd know > better, but I'm 99% certain that we get this directly from PAM (as in, > the application itself provides that data when making a PAM request). > > Looking at a recent auth I performed on my system, I see the raw PAM > data that comes in from (for example) 'su -l' is reported to us as > "service: su-l". > > My assumption is that SSSD's HBAC simply treats that as canonical. > Thanks for reminding me. It now rings the bell. The service name is what application provides when uses pam calls. There is no full enumeration. It is whatever is used by an application. Having a good list would be nice though, at least identifying the applications that we already know use specific service names. -- Thank you, Dmitri Pal Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From o.burtchen at gmx.de Mon May 3 20:01:39 2010 From: o.burtchen at gmx.de (Oliver Burtchen) Date: Mon, 3 May 2010 22:01:39 +0200 Subject: [Freeipa-users] Remarks about the WebUI In-Reply-To: <4BDF0A3C.10104@redhat.com> References: <201005031905.03976.o.burtchen@gmx.de> <4BDF0A3C.10104@redhat.com> Message-ID: <201005032201.40030.o.burtchen@gmx.de> Am Montag, 3. Mai 2010 19:39:08 schrieb Dmitri Pal: > Oliver Burtchen wrote: > > Hi @all, > > > > first, I know freeipa v2 and especially the webui is work in progress in > > an early state. So please tell me if it is not meaningful yet to report > > things about the webui. > > > > What I observed: > > > > In the hbac-section, fields for host, srchost und user are completly > > missing. And the fields for category are left blank, even if setup with > > the cli. This way, you can easily mess up your rules if you use the webui > > at all. > > > > Best regards, > > Oli > > It is a bit early to report such issues. Okay, so time will tell. -- Oliver Burtchen, Berlin From o.burtchen at gmx.de Mon May 3 20:51:10 2010 From: o.burtchen at gmx.de (Oliver Burtchen) Date: Mon, 3 May 2010 22:51:10 +0200 Subject: [Freeipa-users] Is sssd currently useable with freeipa v2 ? In-Reply-To: <4BDF214F.1000701@redhat.com> References: <201004211934.54063.o.burtchen@gmx.de> <4BDF1FEE.3090208@redhat.com> <4BDF214F.1000701@redhat.com> Message-ID: <201005032251.10834.o.burtchen@gmx.de> Am Montag, 3. Mai 2010 21:17:35 schrieb Dmitri Pal: > Stephen Gallagher wrote: > > On 05/03/2010 02:55 PM, Rob Crittenden wrote: > >> Oliver Burtchen wrote: > >>> 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. > > > > I'm going to let Sumit comment on the Bugzilla ticket, since he'd know > > better, but I'm 99% certain that we get this directly from PAM (as in, > > the application itself provides that data when making a PAM request). > > > > Looking at a recent auth I performed on my system, I see the raw PAM > > data that comes in from (for example) 'su -l' is reported to us as > > "service: su-l". > > > > My assumption is that SSSD's HBAC simply treats that as canonical. > > Thanks for reminding me. It now rings the bell. The service name is what > application provides when uses pam calls. There is no full enumeration. > It is whatever is used by an application. > Having a good list would be nice though, at least identifying the > applications that we already know use specific service names. > For the record: After reading Sumits reply at bugzilla and this "In general, the service name is the name of the program used to access the service, not the program used to provide the service. This is why the service wu-ftpd, defines its service name as /etc/pam.d/ftp." quoted from http://www.redhat.com/docs/manuals/linux/RHL-8.0-Manual/ref-guide/s1-pam- config-files.html I tested it a little bit out: If you set a hbac-rule with --service=su-l, it will only apply to "su -l" or "su -", but not to a simple "su". If you set a hbac-rule with --service=su, it will apply to "su -l", "su -"and a simple "su". So my assumption is, that applications do try from a specific name, down to the general one. This is why "sshd" and "ssh" work. Or is it pam who does this magic? Btw: I also think a good list with well known services would be nice, so someone who tries to set up wu-ftpd, like the example in the redhat-docu, uses "ftp", and not "wu-ftpd". It's just a wish for the upcomming documentation. ;-) Best regards, Oli -- Oliver Burtchen, Berlin From sbose at redhat.com Mon May 3 21:16:46 2010 From: sbose at redhat.com (Sumit Bose) Date: Mon, 3 May 2010 23:16:46 +0200 Subject: [Freeipa-users] Is sssd currently useable with freeipa v2 ? In-Reply-To: <201005032251.10834.o.burtchen@gmx.de> References: <201004211934.54063.o.burtchen@gmx.de> <4BDF1FEE.3090208@redhat.com> <4BDF214F.1000701@redhat.com> <201005032251.10834.o.burtchen@gmx.de> Message-ID: <20100503211646.GL18583@localhost.localdomain> On Mon, May 03, 2010 at 10:51:10PM +0200, Oliver Burtchen wrote: > Am Montag, 3. Mai 2010 21:17:35 schrieb Dmitri Pal: > > Stephen Gallagher wrote: > > > On 05/03/2010 02:55 PM, Rob Crittenden wrote: > > >> Oliver Burtchen wrote: > > >>> 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. > > > > > > I'm going to let Sumit comment on the Bugzilla ticket, since he'd know > > > better, but I'm 99% certain that we get this directly from PAM (as in, > > > the application itself provides that data when making a PAM request). > > > > > > Looking at a recent auth I performed on my system, I see the raw PAM > > > data that comes in from (for example) 'su -l' is reported to us as > > > "service: su-l". > > > > > > My assumption is that SSSD's HBAC simply treats that as canonical. > > > > Thanks for reminding me. It now rings the bell. The service name is what > > application provides when uses pam calls. There is no full enumeration. > > It is whatever is used by an application. > > Having a good list would be nice though, at least identifying the > > applications that we already know use specific service names. > > > > For the record: After reading Sumits reply at bugzilla and this > > "In general, the service name is the name of the program used to access the > service, not the program used to provide the service. This is why the service > wu-ftpd, defines its service name as /etc/pam.d/ftp." quoted from > > http://www.redhat.com/docs/manuals/linux/RHL-8.0-Manual/ref-guide/s1-pam- > config-files.html > > I tested it a little bit out: > > If you set a hbac-rule with --service=su-l, it will only apply to "su -l" or > "su -", but not to a simple "su". > > If you set a hbac-rule with --service=su, it will apply to "su -l", "su -"and > a simple "su". > > So my assumption is, that applications do try from a specific name, down to the > general one. This is why "sshd" and "ssh" work. Or is it pam who does this > magic? No it is not PAM, but some kind of error on my side. The strings sssd gets from the LDAP server are not terminated with \0, but the size is known (this is because the ASN.1 coding of the LDAP messages). I was lazy and just compared up to the length return by LDAP. Although the effect might look convenient I think this is an error. I'll try to fix it tomorrow. bye, Sumit > > Btw: I also think a good list with well known services would be nice, so > someone who tries to set up wu-ftpd, like the example in the redhat-docu, uses > "ftp", and not "wu-ftpd". It's just a wish for the upcomming documentation. > ;-) > > Best regards, > Oli > > > -- > Oliver Burtchen, Berlin > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From sbrady at gtfservices.com Mon May 3 22:11:18 2010 From: sbrady at gtfservices.com (Sean Brady) Date: Mon, 3 May 2010 16:11:18 -0600 Subject: [Freeipa-users] Policy functionality of 2.0 requirements dropped? Message-ID: <4BDF4A06.6030702@gtfservices.com> I just checked out the requirements document for 2.0 again and I see that the policy and audit sections indicate that those requirements have been dropped. I didn't see anything on this list about that, although I admit I haven't had time to follow that closely. Can anyone comment on why these have been dropped, and what would replace that functionality? One area of specific concern would be the removal of 1.3.8, "Integrate machine into the existing network by downloading and applying policies related to the machine (network settings, policy, printers)"... Thanks all. From sgallagh at redhat.com Mon May 3 22:32:39 2010 From: sgallagh at redhat.com (Stephen Gallagher) Date: Mon, 03 May 2010 18:32:39 -0400 Subject: [Freeipa-users] Policy functionality of 2.0 requirements dropped? In-Reply-To: <4BDF4A06.6030702@gtfservices.com> References: <4BDF4A06.6030702@gtfservices.com> Message-ID: <4BDF4F07.2060308@redhat.com> On 05/03/2010 06:11 PM, Sean Brady wrote: > I just checked out the requirements document for 2.0 again and I see > that the policy and audit sections indicate that those requirements have > been dropped. I didn't see anything on this list about that, although I > admit I haven't had time to follow that closely. > > Can anyone comment on why these have been dropped, and what would > replace that functionality? One area of specific concern would be the > removal of 1.3.8, "Integrate machine into the existing network by > downloading and applying policies related to the machine (network > settings, policy, printers)"... > > Thanks all. > > You could try Puppet (http://puppet.reductivelabs.com/), which provides most of the functionality IPA v2 was originally going to provide. -- Stephen Gallagher RHCE 804006346421761 Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ From sbrady at gtfservices.com Mon May 3 22:51:36 2010 From: sbrady at gtfservices.com (Sean Brady) Date: Mon, 3 May 2010 16:51:36 -0600 Subject: [Freeipa-users] Policy functionality of 2.0 requirements dropped? In-Reply-To: <4BDF4F07.2060308@redhat.com> References: <4BDF4A06.6030702@gtfservices.com> <4BDF4F07.2060308@redhat.com> Message-ID: <4BDF5378.5080300@gtfservices.com> On 05/03/2010 04:32 PM, Stephen Gallagher wrote: > On 05/03/2010 06:11 PM, Sean Brady wrote: > >> I just checked out the requirements document for 2.0 again and I see >> that the policy and audit sections indicate that those requirements have >> been dropped. I didn't see anything on this list about that, although I >> admit I haven't had time to follow that closely. >> >> Can anyone comment on why these have been dropped, and what would >> replace that functionality? One area of specific concern would be the >> removal of 1.3.8, "Integrate machine into the existing network by >> downloading and applying policies related to the machine (network >> settings, policy, printers)"... >> >> Thanks all. >> >> >> > You could try Puppet (http://puppet.reductivelabs.com/), which provides > most of the functionality IPA v2 was originally going to provide. > > > I was just curious as to the reasoning behind the change. I'm not really that upset about it or anything, except for the configuration download part. That was something that I was really looking forward to. It was just a little bit of a shock to see that on the site without seeing anything about it here first. And as for Puppet, I just can't bring myself to install Ruby on my servers and give up the extra RAM that it needs. They are all tuned VM's that use just enough resources. Perhaps I am succumbing to FUD, but it's not worth it at this point. Maybe this change in direction with FreeI will change that. Well, I suppose now we need to change the name to FreeI, since the PA are gone :). From o.burtchen at gmx.de Mon May 3 22:49:21 2010 From: o.burtchen at gmx.de (Oliver Burtchen) Date: Tue, 4 May 2010 00:49:21 +0200 Subject: [Freeipa-users] Is sssd currently useable with freeipa v2 ? In-Reply-To: <20100503211646.GL18583@localhost.localdomain> References: <201004211934.54063.o.burtchen@gmx.de> <201005032251.10834.o.burtchen@gmx.de> <20100503211646.GL18583@localhost.localdomain> Message-ID: <201005040049.21198.o.burtchen@gmx.de> Am Montag, 3. Mai 2010 23:16:46 schrieb Sumit Bose: > On Mon, May 03, 2010 at 10:51:10PM +0200, Oliver Burtchen wrote: > > Am Montag, 3. Mai 2010 21:17:35 schrieb Dmitri Pal: > > > Stephen Gallagher wrote: > > > > On 05/03/2010 02:55 PM, Rob Crittenden wrote: > > > >> Oliver Burtchen wrote: > > > >>> 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. > > > > > > > > I'm going to let Sumit comment on the Bugzilla ticket, since he'd > > > > know better, but I'm 99% certain that we get this directly from PAM > > > > (as in, the application itself provides that data when making a PAM > > > > request). > > > > > > > > Looking at a recent auth I performed on my system, I see the raw PAM > > > > data that comes in from (for example) 'su -l' is reported to us as > > > > "service: su-l". > > > > > > > > My assumption is that SSSD's HBAC simply treats that as canonical. > > > > > > Thanks for reminding me. It now rings the bell. The service name is > > > what application provides when uses pam calls. There is no full > > > enumeration. It is whatever is used by an application. > > > Having a good list would be nice though, at least identifying the > > > applications that we already know use specific service names. > > > > For the record: After reading Sumits reply at bugzilla and this > > > > "In general, the service name is the name of the program used to access > > the service, not the program used to provide the service. This is why the > > service wu-ftpd, defines its service name as /etc/pam.d/ftp." quoted from > > > > http://www.redhat.com/docs/manuals/linux/RHL-8.0-Manual/ref-guide/s1-pam- > > config-files.html > > > > I tested it a little bit out: > > > > If you set a hbac-rule with --service=su-l, it will only apply to "su -l" > > or "su -", but not to a simple "su". > > > > If you set a hbac-rule with --service=su, it will apply to "su -l", "su > > -"and a simple "su". > > > > So my assumption is, that applications do try from a specific name, down > > to the general one. This is why "sshd" and "ssh" work. Or is it pam who > > does this magic? > > No it is not PAM, but some kind of error on my side. The strings sssd gets > from the LDAP server are not terminated with \0, but the size is known > (this is because the ASN.1 coding of the LDAP messages). I was lazy and > just compared up to the length return by LDAP. Although the effect might > look convenient I think this is an error. I'll try to fix it tomorrow. Yes, at first sight it looked convenient. But arghh, currently a hbac-rule for "su" also matches "sudo"? Well, good to nailed it down. ;-) I'll appreciate your corrections. But despite that it would be very nice to have some way to set a rule for a "category" or group of services. It is very error-prone to administer the same set of rules for example for ssh, su, login seperately. I can think of different approaches to achieve that, but don't know what's best. Maybe it should be possible to collect services in a group. Then the frontend (cli or webui) could apply modifications to all members of this named group, if asked so? Best regards, Oli > > bye, > Sumit > > > Btw: I also think a good list with well known services would be nice, so > > someone who tries to set up wu-ftpd, like the example in the redhat-docu, > > uses "ftp", and not "wu-ftpd". It's just a wish for the upcomming > > documentation. ;-) > > > > Best regards, > > Oli > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > -- Oliver Burtchen, Berlin From dpal at redhat.com Mon May 3 23:58:23 2010 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 03 May 2010 19:58:23 -0400 Subject: [Freeipa-users] Policy functionality of 2.0 requirements dropped? In-Reply-To: <4BDF5378.5080300@gtfservices.com> References: <4BDF4A06.6030702@gtfservices.com> <4BDF4F07.2060308@redhat.com> <4BDF5378.5080300@gtfservices.com> Message-ID: <4BDF631F.2030708@redhat.com> Sean Brady wrote: > > On 05/03/2010 04:32 PM, Stephen Gallagher wrote: >> On 05/03/2010 06:11 PM, Sean Brady wrote: >>> I just checked out the requirements document for 2.0 again and I see >>> that the policy and audit sections indicate that those requirements >>> have >>> been dropped. I didn't see anything on this list about that, although I >>> admit I haven't had time to follow that closely. >>> >>> Can anyone comment on why these have been dropped, and what would >>> replace that functionality? One area of specific concern would be the >>> removal of 1.3.8, "Integrate machine into the existing network by >>> downloading and applying policies related to the machine (network >>> settings, policy, printers)"... >>> >>> Thanks all. >>> >>> >> You could try Puppet (http://puppet.reductivelabs.com/), which provides >> most of the functionality IPA v2 was originally going to provide. >> >> > > > I was just curious as to the reasoning behind the change. I'm not > really that upset about it or anything, except for the configuration > download part. That was something that I was really looking forward > to. It was just a little bit of a shock to see that on the site > without seeing anything about it here first. > > And as for Puppet, I just can't bring myself to install Ruby on my > servers and give up the extra RAM that it needs. They are all tuned > VM's that use just enough resources. Perhaps I am succumbing to FUD, > but it's not worth it at this point. Maybe this change in direction > with FreeI will change that. > > Well, I suppose now we need to change the name to FreeI, since the PA > are gone :). This change happened quite some time ago. And as far as I recall there have been an announcement about it. We can dig archives but I remember writing about it. Also the web site has been updated several months ago to reflect the reality. The IPA is still IPA though. We are not going to change the name. The goal is ambitious but still doable. But the change of course is that for policy management we should not invent the wheel but rather integrate with one of the exiting system/configuration management solutions. And when time comes we will look in this. The same with the audit. The problem of audit needs to be solved with the open source solution eventually but currently this space is very crowded and we have not enough resources to solve I, P & A at the same time. We realized that it is not realistic and decided to focus on I and make it right. There is plenty of work in this area that would be more interesting for everybody than trying to build audit. I am talking about cross domain trusts, key management, user authentication with the smart cards and other features that land on the I side. -- Thank you, Dmitri Pal Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From dpal at redhat.com Tue May 4 00:02:42 2010 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 03 May 2010 20:02:42 -0400 Subject: [Freeipa-users] Is sssd currently useable with freeipa v2 ? In-Reply-To: <201005040049.21198.o.burtchen@gmx.de> References: <201004211934.54063.o.burtchen@gmx.de> <201005032251.10834.o.burtchen@gmx.de> <20100503211646.GL18583@localhost.localdomain> <201005040049.21198.o.burtchen@gmx.de> Message-ID: <4BDF6422.1050709@redhat.com> Oliver Burtchen wrote: > Am Montag, 3. Mai 2010 23:16:46 schrieb Sumit Bose: > >> On Mon, May 03, 2010 at 10:51:10PM +0200, Oliver Burtchen wrote: >> >>> Am Montag, 3. Mai 2010 21:17:35 schrieb Dmitri Pal: >>> >>>> Stephen Gallagher wrote: >>>> >>>>> On 05/03/2010 02:55 PM, Rob Crittenden wrote: >>>>> >>>>>> Oliver Burtchen wrote: >>>>>> >>>>>>> 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. >>>>>> >>>>> I'm going to let Sumit comment on the Bugzilla ticket, since he'd >>>>> know better, but I'm 99% certain that we get this directly from PAM >>>>> (as in, the application itself provides that data when making a PAM >>>>> request). >>>>> >>>>> Looking at a recent auth I performed on my system, I see the raw PAM >>>>> data that comes in from (for example) 'su -l' is reported to us as >>>>> "service: su-l". >>>>> >>>>> My assumption is that SSSD's HBAC simply treats that as canonical. >>>>> >>>> Thanks for reminding me. It now rings the bell. The service name is >>>> what application provides when uses pam calls. There is no full >>>> enumeration. It is whatever is used by an application. >>>> Having a good list would be nice though, at least identifying the >>>> applications that we already know use specific service names. >>>> >>> For the record: After reading Sumits reply at bugzilla and this >>> >>> "In general, the service name is the name of the program used to access >>> the service, not the program used to provide the service. This is why the >>> service wu-ftpd, defines its service name as /etc/pam.d/ftp." quoted from >>> >>> http://www.redhat.com/docs/manuals/linux/RHL-8.0-Manual/ref-guide/s1-pam- >>> config-files.html >>> >>> I tested it a little bit out: >>> >>> If you set a hbac-rule with --service=su-l, it will only apply to "su -l" >>> or "su -", but not to a simple "su". >>> >>> If you set a hbac-rule with --service=su, it will apply to "su -l", "su >>> -"and a simple "su". >>> >>> So my assumption is, that applications do try from a specific name, down >>> to the general one. This is why "sshd" and "ssh" work. Or is it pam who >>> does this magic? >>> >> No it is not PAM, but some kind of error on my side. The strings sssd gets >> from the LDAP server are not terminated with \0, but the size is known >> (this is because the ASN.1 coding of the LDAP messages). I was lazy and >> just compared up to the length return by LDAP. Although the effect might >> look convenient I think this is an error. I'll try to fix it tomorrow. >> > > Yes, at first sight it looked convenient. But arghh, currently a hbac-rule for > "su" also matches "sudo"? Well, good to nailed it down. ;-) I'll appreciate > your corrections. > > But despite that it would be very nice to have some way to set a rule for a > "category" or group of services. It is very error-prone to administer the same > set of rules for example for ssh, su, login seperately. I can think of > different approaches to achieve that, but don't know what's best. > > Maybe it should be possible to collect services in a group. Then the frontend > (cli or webui) could apply modifications to all members of this named group, if > asked so? > > Best regards, > Oli > > That would require schema changes. It is doable but I am not sure is the best approach. I would rather suggest we treat the value as a space separated list or a MV attribute and have a way to create MV values in a simpler ways. We need to think about it. I will file an ER. > >> bye, >> Sumit >> >> >>> Btw: I also think a good list with well known services would be nice, so >>> someone who tries to set up wu-ftpd, like the example in the redhat-docu, >>> uses "ftp", and not "wu-ftpd". It's just a wish for the upcomming >>> documentation. ;-) >>> >>> Best regards, >>> Oli >>> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users >> >> > > -- Thank you, Dmitri Pal Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From sbrady at gtfservices.com Tue May 4 00:30:42 2010 From: sbrady at gtfservices.com (Sean Brady) Date: Mon, 3 May 2010 18:30:42 -0600 Subject: [Freeipa-users] Policy functionality of 2.0 requirements dropped? In-Reply-To: <4BDF631F.2030708@redhat.com> References: <4BDF4A06.6030702@gtfservices.com> <4BDF4F07.2060308@redhat.com> <4BDF5378.5080300@gtfservices.com> <4BDF631F.2030708@redhat.com> Message-ID: <4BDF6AB2.4050405@gtfservices.com> On 05/03/2010 05:58 PM, Dmitri Pal wrote: > Sean Brady wrote: > >> On 05/03/2010 04:32 PM, Stephen Gallagher wrote: >> >>> On 05/03/2010 06:11 PM, Sean Brady wrote: >>> >>>> I just checked out the requirements document for 2.0 again and I see >>>> that the policy and audit sections indicate that those requirements >>>> have >>>> been dropped. I didn't see anything on this list about that, although I >>>> admit I haven't had time to follow that closely. >>>> >>>> Can anyone comment on why these have been dropped, and what would >>>> replace that functionality? One area of specific concern would be the >>>> removal of 1.3.8, "Integrate machine into the existing network by >>>> downloading and applying policies related to the machine (network >>>> settings, policy, printers)"... >>>> >>>> Thanks all. >>>> >>>> >>>> >>> You could try Puppet (http://puppet.reductivelabs.com/), which provides >>> most of the functionality IPA v2 was originally going to provide. >>> >>> >>> >> >> I was just curious as to the reasoning behind the change. I'm not >> really that upset about it or anything, except for the configuration >> download part. That was something that I was really looking forward >> to. It was just a little bit of a shock to see that on the site >> without seeing anything about it here first. >> >> And as for Puppet, I just can't bring myself to install Ruby on my >> servers and give up the extra RAM that it needs. They are all tuned >> VM's that use just enough resources. Perhaps I am succumbing to FUD, >> but it's not worth it at this point. Maybe this change in direction >> with FreeI will change that. >> >> Well, I suppose now we need to change the name to FreeI, since the PA >> are gone :). >> > This change happened quite some time ago. > And as far as I recall there have been an announcement about it. > We can dig archives but I remember writing about it. > Works for me. It must have been before I joined the ML and I just checked the website again. > Also the web site has been updated several months ago to reflect the > reality. > The IPA is still IPA though. We are not going to change the name. > The goal is ambitious but still doable. > But the change of course is that for policy management we should not > invent the wheel but rather integrate with one of the exiting > system/configuration management solutions. And when time comes we will > look in this. > I 100% agree that there are lots of tools out there to do this job, and it doesn't make sense to re-invent the wheel. > The same with the audit. The problem of audit needs to be solved with > the open source solution eventually but currently this space is very > crowded and we have not enough resources to solve I, P& A at the same > time. We realized that it is not realistic and decided to focus on I and > make it right. There is plenty of work in this area that would be more > interesting for everybody than trying to build audit. I am talking about > cross domain trusts, key management, user authentication with the smart > cards and other features that land on the I side. > > > I hear the lack of resources as well. It makes complete sense that the resources that we have are allocated into making the most important part of the package (the "I") work right. I can do the "P" and the "A" right now separately. Perhaps it makes sense to use rsyslog/rsyslogd for the logging, along with some tools like CFt/Func for the "P" and "A" (you know, the fantastic Red Hat ET suite +rsyslog) to start with. Would it be of interest to the group for me to do a little leg work on a proposal for gathering all these tools together in a cohesive suite? I still owe some documentation work on v2, but I've been busy with the "project that just wont die". Thanks for your response and your hard work. From natxo.asenjo at gmail.com Tue May 4 07:50:47 2010 From: natxo.asenjo at gmail.com (Natxo Asenjo) Date: Tue, 4 May 2010 09:50:47 +0200 Subject: [Freeipa-users] Policy functionality of 2.0 requirements dropped? In-Reply-To: <4BDF5378.5080300@gtfservices.com> References: <4BDF4A06.6030702@gtfservices.com> <4BDF4F07.2060308@redhat.com> <4BDF5378.5080300@gtfservices.com> Message-ID: > On 05/03/2010 04:32 PM, Stephen Gallagher wrote: >> >> On 05/03/2010 06:11 PM, Sean Brady wrote: >> You could try Puppet (http://puppet.reductivelabs.com/), which provides >> most of the functionality IPA v2 was originally going to provide. > And as for Puppet, I just can't bring myself to install Ruby on my servers > and give up the extra RAM that it needs. ?They are all tuned VM's that use > just enough resources. ?Perhaps I am succumbing to FUD, but it's not worth > it at this point. ?Maybe this change in direction with FreeI will change > that. then go with cfengine (http://www.cfengine.org) , tested solution and not a resource pig. It integrates great with netgroups, by the way. There are packages for every distribution. I run it in a esx cluster (both the esx servers and the linux vm's and it works great). -- natxo asenjo From Andy.Singleton at tipp24os.co.uk Tue May 4 13:48:45 2010 From: Andy.Singleton at tipp24os.co.uk (Andy Singleton) Date: Tue, 4 May 2010 14:48:45 +0100 Subject: [Freeipa-users] Recovering admin key Message-ID: <1CD40A4DEEA320479C98D8A93A5C690602BE4CF4@waterloo.t24uk.tipp24.net> Hello, This topic might have been covered before, so I hope im not rehashing old ground here. We have a multi-master ipa 1.2.2 installation. Its been running fine (give or take) for a while now. But, the "admin" account password has been reset to an unknown value. Normally we store our passwords in Password Safe, but this time it wasn't done. So we have effectively locked ourselves out from the admin account. Is there a simple way to reset it? Thanks Andy -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Tue May 4 14:00:02 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 04 May 2010 10:00:02 -0400 Subject: [Freeipa-users] Recovering admin key In-Reply-To: <1CD40A4DEEA320479C98D8A93A5C690602BE4CF4@waterloo.t24uk.tipp24.net> References: <1CD40A4DEEA320479C98D8A93A5C690602BE4CF4@waterloo.t24uk.tipp24.net> Message-ID: <4BE02862.5090104@redhat.com> Andy Singleton wrote: > Hello, > > > > This topic might have been covered before, so I hope im not rehashing > old ground here. > > > > We have a multi-master ipa 1.2.2 installation. Its been running fine > (give or take) for a while now. > > > > But, the ?admin? account password has been reset to an unknown value. > > Normally we store our passwords in Password Safe, but this time it > wasn?t done. > > So we have effectively locked ourselves out from the admin account. > > > > Is there a simple way to reset it? % ldappasswd -Z -D "cn=directory manager" -W -S uid=admin,cn=users,cn=accounts,dc=example,dc=com You'll be prompted twice for the new password, then the password for your directory manager (this is the LDAP password). You may have to configure openLDAP to trust your CA. I just created ~/.ldaprc and set it to this: TLS_CACERT /etc/ipa/ca.crt rob From dpal at redhat.com Tue May 4 14:32:55 2010 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 04 May 2010 10:32:55 -0400 Subject: [Freeipa-users] Policy functionality of 2.0 requirements dropped? In-Reply-To: <4BDF6AB2.4050405@gtfservices.com> References: <4BDF4A06.6030702@gtfservices.com> <4BDF4F07.2060308@redhat.com> <4BDF5378.5080300@gtfservices.com> <4BDF631F.2030708@redhat.com> <4BDF6AB2.4050405@gtfservices.com> Message-ID: <4BE03017.6010800@redhat.com> [snip] > I hear the lack of resources as well. It makes complete sense that the > resources that we have are allocated into making the most important > part of the package (the "I") work right. I can do the "P" and the "A" > right now separately. > > Perhaps it makes sense to use rsyslog/rsyslogd for the logging, along > with some tools like CFt/Func for the "P" and "A" (you know, the > fantastic Red Hat ET suite +rsyslog) to start with. > The only sub project that is left out of our "A" effort is ELAPI https://fedorahosted.org/ELAPI/ But it is a bit in flux. It is designed up to some point but desperately needs a month of head down work to get it to the point when the loose ends scattered around start to make sense. I just do not have time to work on it at all. And it would be nightmare for someone to try to untangle my incomplete ideas himself. I would love someone to eventually take it over because I as a manager should not be the core contributor to a project. This does not scale. I think rsyslog is good but not good enough and eventually log collection should be brought up to the next level. > Would it be of interest to the group for me to do a little leg work on > a proposal for gathering all these tools together in a cohesive suite? > I still owe some documentation work on v2, but I've been busy with the > "project that just wont die". > Please write your ideas. It is always beneficial to evaluate options come up with a plan. > Thanks for your response and your hard work. Thank you for your interest and participation. -- Thank you, Dmitri Pal Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From ryan at pet.ubc.ca Thu May 6 22:59:45 2010 From: ryan at pet.ubc.ca (Ryan Thomson) Date: Thu, 06 May 2010 15:59:45 -0700 Subject: [Freeipa-users] User Private Groups Message-ID: <4BE349E1.7020802@pet.ubc.ca> Hi list, I am wondering if FreeIPA is planning to conform to RHEL's user private group (UPG) scheme? I think having an option to enable the UPG scheme would be beneficial. Adding a user to the v2 beta reveals that the UPG scheme is not currently being followed with all new accounts auto-added to the default "ipausers" group. I noticed an older mailing list post by rob saying that UPG was being investigated. Has there been any progress in that investigation? Any decisions? Thank you, --Ryan From ryan at pet.ubc.ca Thu May 6 23:01:19 2010 From: ryan at pet.ubc.ca (Ryan Thomson) Date: Thu, 06 May 2010 16:01:19 -0700 Subject: [Freeipa-users] User Private Groups In-Reply-To: <10145_1273186810_1273186810_4BE349E1.7020802@pet.ubc.ca> References: <10145_1273186810_1273186810_4BE349E1.7020802@pet.ubc.ca> Message-ID: <4BE34A3F.6060508@pet.ubc.ca> Wow, I need to improve my search skills: http://freeipa.org/page/IPAv2_alpha2 My answer is at the bottom of the page! My apologies, everyone. --Ryan Ryan Thomson wrote: > Hi list, > > I am wondering if FreeIPA is planning to conform to RHEL's user private > group (UPG) scheme? I think having an option to enable the UPG scheme > would be beneficial. > > Adding a user to the v2 beta reveals that the UPG scheme is not > currently being followed with all new accounts auto-added to the default > "ipausers" group. > > I noticed an older mailing list post by rob saying that UPG was being > investigated. Has there been any progress in that investigation? Any > decisions? > > Thank you, > > --Ryan > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From dpal at redhat.com Thu May 6 23:14:17 2010 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 06 May 2010 19:14:17 -0400 Subject: [Freeipa-users] User Private Groups In-Reply-To: <4BE34A3F.6060508@pet.ubc.ca> References: <10145_1273186810_1273186810_4BE349E1.7020802@pet.ubc.ca> <4BE34A3F.6060508@pet.ubc.ca> Message-ID: <4BE34D49.9020202@redhat.com> Ryan Thomson wrote: > Wow, I need to improve my search skills: > http://freeipa.org/page/IPAv2_alpha2 > > My answer is at the bottom of the page! > > My apologies, everyone. UPG will be handled using special DS plugin that will automatically maintain private group entry in synch with parent user entry. This work is done and being tested. It might not be in upcoming alpha 3 but it is close to becoming available. Thanks Dmitri > > --Ryan > > Ryan Thomson wrote: >> Hi list, >> >> I am wondering if FreeIPA is planning to conform to RHEL's user >> private group (UPG) scheme? I think having an option to enable the >> UPG scheme would be beneficial. >> >> Adding a user to the v2 beta reveals that the UPG scheme is not >> currently being followed with all new accounts auto-added to the >> default "ipausers" group. >> >> I noticed an older mailing list post by rob saying that UPG was being >> investigated. Has there been any progress in that investigation? Any >> decisions? >> >> Thank you, >> >> --Ryan >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From rcritten at redhat.com Thu May 6 23:16:49 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 06 May 2010 19:16:49 -0400 Subject: [Freeipa-users] User Private Groups In-Reply-To: <4BE34A3F.6060508@pet.ubc.ca> References: <10145_1273186810_1273186810_4BE349E1.7020802@pet.ubc.ca> <4BE34A3F.6060508@pet.ubc.ca> Message-ID: <4BE34DE1.8010902@redhat.com> Ryan Thomson wrote: > Wow, I need to improve my search skills: > http://freeipa.org/page/IPAv2_alpha2 > > My answer is at the bottom of the page! > > My apologies, everyone. No worries. We're going to build this on a new feature in 389-ds, Managed Entries (http://directory.fedoraproject.org/wiki/Managed_Entry_Design) We need an enhancement in the DNA plugin to be able to keep the uidNumber and gidNumber the same but the Managed Entries plugin does most of the heavy lifting of avoiding race conditions for us already. At this point we just need to wait for the next 389-ds release which should be in the next few weeks. Once that is available we can create our private groups. rob > > --Ryan > > Ryan Thomson wrote: >> Hi list, >> >> I am wondering if FreeIPA is planning to conform to RHEL's user >> private group (UPG) scheme? I think having an option to enable the UPG >> scheme would be beneficial. >> >> Adding a user to the v2 beta reveals that the UPG scheme is not >> currently being followed with all new accounts auto-added to the >> default "ipausers" group. >> >> I noticed an older mailing list post by rob saying that UPG was being >> investigated. Has there been any progress in that investigation? Any >> decisions? >> >> Thank you, >> >> --Ryan >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From ryan at pet.ubc.ca Thu May 6 23:38:15 2010 From: ryan at pet.ubc.ca (Ryan Thomson) Date: Thu, 6 May 2010 16:38:15 -0700 Subject: [Freeipa-users] User Private Groups In-Reply-To: <4BE34DE1.8010902@redhat.com> References: <10145_1273186810_1273186810_4BE349E1.7020802@pet.ubc.ca> <4BE34A3F.6060508@pet.ubc.ca> <4BE34DE1.8010902@redhat.com> Message-ID: <2DFC8A74-E220-40C4-86CE-2913F0895F23@pet.ubc.ca> Thanks for the responses, Rob and Dmitri! The solution sounds very elegant. I await UPG and the next FreeIPA release (whether or not it has UPG) eagerly. --Ryan On 2010-05-06, at 4:16 PM, Rob Crittenden wrote: > Ryan Thomson wrote: >> Wow, I need to improve my search skills: http://freeipa.org/page/IPAv2_alpha2 >> My answer is at the bottom of the page! >> My apologies, everyone. > > No worries. > > We're going to build this on a new feature in 389-ds, Managed Entries (http://directory.fedoraproject.org/wiki/Managed_Entry_Design) > > We need an enhancement in the DNA plugin to be able to keep the uidNumber and gidNumber the same but the Managed Entries plugin does most of the heavy lifting of avoiding race conditions for us already. > > At this point we just need to wait for the next 389-ds release which should be in the next few weeks. Once that is available we can create our private groups. > > rob > >> --Ryan >> Ryan Thomson wrote: >>> Hi list, >>> >>> I am wondering if FreeIPA is planning to conform to RHEL's user private group (UPG) scheme? I think having an option to enable the UPG scheme would be beneficial. >>> >>> Adding a user to the v2 beta reveals that the UPG scheme is not currently being followed with all new accounts auto-added to the default "ipausers" group. >>> >>> I noticed an older mailing list post by rob saying that UPG was being investigated. Has there been any progress in that investigation? Any decisions? >>> >>> Thank you, >>> >>> --Ryan >>> >>> _______________________________________________ >>> Freeipa-users mailing list >>> Freeipa-users at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-users >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > From rcritten at redhat.com Fri May 7 19:56:19 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 07 May 2010 15:56:19 -0400 Subject: [Freeipa-users] Announcing FreeIPA v2 Server Alpha 3 Release Message-ID: <4BE47063.4030901@redhat.com> To all freeipa-interest, freeipa-users and freeipa-devel list members, The FreeIPA project team is pleased to announce the availability of the Alpha 3 release of freeIPA 2.0 server [1]. Binaries are available for F-12 and F-13. This alpha is mostly a bug fix release over the previous alpha. We have started the process of polishing so things should generally work more smoothly and look better. There are few visual improvements in the UI, those should appear in the next release. Please do not hesitate to share feedback, criticism or bugs with us on our mailing list: freeipa-users at redhat.com The big changes in this release are: - better i18n support including a few translations - the XML-RPC API changed so it is not compatible with previous releases - use mod_wsgi instead of mod_python - the CA is a required component and is now configured by default. Pass --selfsign to the installer to use the old self-signed CA - man page for the ipa command - A default Host-Based Access Control (HBAC) rule is created that grants all users the ability to log into any host from any host. This was done to simplify initial testing, it is expected this rule, allow_all, will be removed before you deploy. - We no longer enable nscd, sssd handles caching now Known issues: - The CA must be installed in the en_US locale (#588375) A more complete, semi-high-level list of changes since the last alpha are: - Fix memory crash-bug in ipa-join - Add pwpolicy2 plugin, future replacement for pwpolicy - CSRs that don't include NEW in the header/footer blocks should work now - Lots of clean-ups in ipa-client-install - ipa-server-install and ipa-client-install now use backed-up files and state in /var/lib/ipa and /var/lib/ipa-client to determine whether they are already configured or not - Fixed bug in some DNS entries that were missing a trailing dot (.) - Fix bug in password plugin that prevented ldappasswd from working on non-kerberized users - In the client installer we will have certmonger issue certificate requests using the subject base that IPA is configured with. This will make certmonger play nicer with the selfsign CA. - IPA works when using external CA option again - Stop using LDAPv2-style escaped DNs where possible - Updated MITM integration with dogtag - Anonymous VLV is enabled when the compat plugin is enabled making Solaris 10 clients happy - Add a CRL URI to certificates that are issued by dogtag - Added an ipa man page - XML-RPC signature change. This will affect older alphas command-line utilities trying to talk to a new server - Fixed bug in host plugin where deleting a non-qualified hostname would delete just the host, not the service entries associated with that host. - ipa-replica-manage now uses kerberos to delete and list servers. Add still requires the DM password - Provide feedback if a -mod command is executed and no changes are performed - Don't log passwords into files during installation - Add option to enable pam_mkhomedirs in the IPA client installer - Fixed a number of bugs in the pwpolicy plugin - More detailed error messages when entries are not found - Viewing binary in the UI shouldn't cause it to fail - dogtag is a required component and now configured by default - Run the XML-RPC server under mod_wsgi instead of mod_python - Fix the --all and --raw options - 8 translations: - Bengali India - Indonesian - Ukrainian - Kannada - Polish - Russian - Spanish - Chinese Simplified - Other minor polish and bug fixes rob [1] http://www.freeipa.org/page/Downloads From o.burtchen at gmx.de Sat May 8 03:37:27 2010 From: o.burtchen at gmx.de (Oliver Burtchen) Date: Sat, 8 May 2010 05:37:27 +0200 Subject: [Freeipa-users] Announcing FreeIPA v2 Server Alpha 3 Release In-Reply-To: <4BE47063.4030901@redhat.com> References: <4BE47063.4030901@redhat.com> Message-ID: <201005080537.27529.o.burtchen@gmx.de> Hi @all, as long year Fedora and formerly Red Hat Linux user and interested tester of freeipa v2 lately, I want just congratulate for the next (alpha) release of freeipa. Thanks to the developers and Red Hat at all for the ongoing work, friendly support in the mailing lists and contributions to the open source community! Best regards, Oli Am Freitag, 7. Mai 2010 21:56:19 schrieb Rob Crittenden: > To all freeipa-interest, freeipa-users and freeipa-devel list members, > > The FreeIPA project team is pleased to announce the availability of the > Alpha 3 release of freeIPA 2.0 server [1]. Binaries are available for > F-12 and F-13. > > This alpha is mostly a bug fix release over the previous alpha. We have > started the process of polishing so things should generally work more > smoothly and look better. There are few visual improvements in the UI, > those should appear in the next release. > > Please do not hesitate to share feedback, criticism or bugs with us on > our mailing list: freeipa-users at redhat.com > > The big changes in this release are: > - better i18n support including a few translations > - the XML-RPC API changed so it is not compatible with previous releases > - use mod_wsgi instead of mod_python > - the CA is a required component and is now configured by default. > Pass --selfsign to the installer to use the old self-signed CA > - man page for the ipa command > - A default Host-Based Access Control (HBAC) rule is created that > grants all users the ability to log into any host from any host. This > was done to simplify initial testing, it is expected this rule, > allow_all, will be removed before you deploy. > - We no longer enable nscd, sssd handles caching now > > Known issues: > - The CA must be installed in the en_US locale (#588375) > > A more complete, semi-high-level list of changes since the last alpha are: > - Fix memory crash-bug in ipa-join > - Add pwpolicy2 plugin, future replacement for pwpolicy > - CSRs that don't include NEW in the header/footer blocks should work now > - Lots of clean-ups in ipa-client-install > - ipa-server-install and ipa-client-install now use backed-up files and > state in /var/lib/ipa and /var/lib/ipa-client to determine whether they > are already configured or not > - Fixed bug in some DNS entries that were missing a trailing dot (.) > - Fix bug in password plugin that prevented ldappasswd from working on > non-kerberized users > - In the client installer we will have certmonger issue certificate > requests using the subject base that IPA is configured with. This will > make certmonger play nicer with the selfsign CA. > - IPA works when using external CA option again > - Stop using LDAPv2-style escaped DNs where possible > - Updated MITM integration with dogtag > - Anonymous VLV is enabled when the compat plugin is enabled making > Solaris 10 clients happy > - Add a CRL URI to certificates that are issued by dogtag > - Added an ipa man page > - XML-RPC signature change. This will affect older alphas command-line > utilities trying to talk to a new server > - Fixed bug in host plugin where deleting a non-qualified hostname would > delete just the host, not the service entries associated with that host. > - ipa-replica-manage now uses kerberos to delete and list servers. Add > still requires the DM password > - Provide feedback if a -mod command is executed and no changes are > performed > - Don't log passwords into files during installation > - Add option to enable pam_mkhomedirs in the IPA client installer > - Fixed a number of bugs in the pwpolicy plugin > - More detailed error messages when entries are not found > - Viewing binary in the UI shouldn't cause it to fail > - dogtag is a required component and now configured by default > - Run the XML-RPC server under mod_wsgi instead of mod_python > - Fix the --all and --raw options > - 8 translations: > - Bengali India > - Indonesian > - Ukrainian > - Kannada > - Polish > - Russian > - Spanish > - Chinese Simplified > - Other minor polish and bug fixes > > rob > > [1] http://www.freeipa.org/page/Downloads > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > -- Oliver Burtchen, Berlin From rob.townley at gmail.com Tue May 11 21:42:26 2010 From: rob.townley at gmail.com (Rob Townley) Date: Tue, 11 May 2010 16:42:26 -0500 Subject: [Freeipa-users] Give laptops bidirectional anywhere access to freeipa and /home/ Message-ID: Microsoft is touting "Direct Access" as a main reason to upgrade to Win2008R2 / Win7. Microsoft makes it seem like a magical feature, but could be done using existing technology. The reality is that discontinuous offline access to ActiveDirectory was not thought out well in the first place. Now that they have a solution, you have to upgrade all servers and workstations to solve a 10 year old issue. WHY: The open source world is very close to having a Direct Access equivalent that is LinMacWin crossplatform and backported to older windows versions. The main item missing is centralized key management. Always on access to freeipa. Passwords are always up-to-date. Enables /home/user/ anywhere user's laptop is located. Authentication tokens are always kept up-to-date. Push updates to remote (on the other side of NATs) laptops at worker's home or hotel. It fits in well with freeipa's inventory of machines in LDAP / DNS / CA. Enables more seamless branch office and home office functionality. HOW: Use existing cross platform tunneling and tap devices for LinMacWin - very well tested. Comes with tinc-vpn. tinc-vpn for the virtual IP addresses. These are secondary IP addresses all machines would have. dynamic dns port numbers stored in bind's SRV or TXT records for easy configuration. tinc-vpn keys stored in dns KEY record for key management. tinc-vpn can use IPv6 if needed. tinc-vpn for the encryption now, ipSec later? FreeIPA provides the centralized management infrastructure that tinc-vpn like solutions are missing. From rob.townley at gmail.com Tue May 11 22:12:53 2010 From: rob.townley at gmail.com (Rob Townley) Date: Tue, 11 May 2010 17:12:53 -0500 Subject: [Freeipa-users] Give laptops bidirectional anywhere access to freeipa and /home/ Message-ID: Microsoft is touting "Direct Access" as a main reason to upgrade to Win2008R2 / Win7. Microsoft makes it seem like a magical feature, but could be done using existing technology. The reality is that discontinuous offline access to ActiveDirectory was not thought out well in the first place. Now that they have a solution, you have to upgrade all servers and workstations to solve a 10 year old issue. WHY: The open source world is very close to having a Direct Access equivalent that is LinMacWin crossplatform and backported to older windows versions. The main item missing is centralized key management. Always on access to freeipa. Passwords are always up-to-date. Enables /home/user/ anywhere user's laptop is located. Authentication tokens are always kept up-to-date. Push updates to remote (on the other side of NATs) laptops at worker's home or hotel. It fits in well with freeipa's inventory of machines in LDAP / DNS / CA. Enables more seamless branch office and home office functionality. HOW: Use existing cross platform tunneling and tap devices for LinMacWin - very well tested. Comes with tinc-vpn. tinc-vpn for the virtual IP addresses. These are secondary IP addresses all machines would have. dynamic dns port numbers stored in bind's SRV or TXT records for easy configuration. tinc-vpn keys stored in dns KEY record for key management. tinc-vpn can use IPv6 if needed. tinc-vpn for the encryption now, ipSec later? FreeIPA provides the centralized management infrastructure that tinc-vpn like solutions are missing. From chorn at fluxcoil.net Wed May 12 06:54:57 2010 From: chorn at fluxcoil.net (Christian Horn) Date: Wed, 12 May 2010 08:54:57 +0200 Subject: [Freeipa-users] Give laptops bidirectional anywhere access to freeipa and /home/ In-Reply-To: References: Message-ID: <20100512065457.GA12837@fluxcoil.net> On Tue, May 11, 2010 at 04:42:26PM -0500, Rob Townley wrote: > Microsoft is touting "Direct Access" as a main reason to upgrade to > Win2008R2 / Win7. All i see there functionalitywise can be provided by a vpn-endpoint using kerberos/ldap for authentication/authorization. As a feature i read 'use homeshare without using the vpn' but in the end its just 'using a remote filesystem using the computer principal for authentication'. > HOW: > Use existing cross platform tunneling and tap devices for LinMacWin - > very well tested. Comes with tinc-vpn. > tinc-vpn for the virtual IP addresses. These are secondary IP > addresses all machines would have. > dynamic dns port numbers stored in bind's SRV or TXT records for easy > configuration. > tinc-vpn keys stored in dns KEY record for key management. > tinc-vpn can use IPv6 if needed. > tinc-vpn for the encryption now, ipSec later? > > FreeIPA provides the centralized management infrastructure that > tinc-vpn like solutions are missing. If tinc can already work using kerberos/ldap for authentication/au- thorization then you could create a howto or maybe tinc-package with the appropriate libraries. This would then add vpn-endpoint functionality to freeipa. Christian From rcritten at redhat.com Wed May 12 15:54:58 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 12 May 2010 11:54:58 -0400 Subject: [Freeipa-users] Give laptops bidirectional anywhere access to freeipa and /home/ In-Reply-To: References: Message-ID: <4BEACF52.7070305@redhat.com> Rob Townley wrote: > Microsoft is touting "Direct Access" as a main reason to upgrade to > Win2008R2 / Win7. > Microsoft makes it seem like a magical feature, but could be done > using existing technology. > The reality is that discontinuous offline access to ActiveDirectory > was not thought out well in the first place. > Now that they have a solution, you have to upgrade all servers and > workstations to solve a 10 year old issue. Yes, sssd should buy us nice offline support for laptops. > WHY: > The open source world is very close to having a Direct Access > equivalent that is LinMacWin crossplatform and backported to older > windows versions. The main item missing is centralized key management. > Always on access to freeipa. > Passwords are always up-to-date. > Enables /home/user/ anywhere user's laptop is located. > Authentication tokens are always kept up-to-date. > Push updates to remote (on the other side of NATs) laptops at worker's > home or hotel. > It fits in well with freeipa's inventory of machines in LDAP / DNS / CA. > Enables more seamless branch office and home office functionality. Well, we don't push data around just yet. What sort of updates are you referring to? > HOW: > Use existing cross platform tunneling and tap devices for LinMacWin - > very well tested. Comes with tinc-vpn. > tinc-vpn for the virtual IP addresses. These are secondary IP > addresses all machines would have. > dynamic dns port numbers stored in bind's SRV or TXT records for easy > configuration. > tinc-vpn keys stored in dns KEY record for key management. > tinc-vpn can use IPv6 if needed. > tinc-vpn for the encryption now, ipSec later? > > > FreeIPA provides the centralized management infrastructure that > tinc-vpn like solutions are missing. Ok, so are you proposing to use tinc-vpn in conjunction with IPA? What sort of management tools would one need in order to maintain the key material, and what kind of keys are these? (e.g. SSL certs, ssh keys, gpg, etc) cheers rob From chorn at fluxcoil.net Wed May 12 17:28:29 2010 From: chorn at fluxcoil.net (Christian Horn) Date: Wed, 12 May 2010 19:28:29 +0200 Subject: [Freeipa-users] Give laptops bidirectional anywhere access to freeipa and /home/ In-Reply-To: References: <20100512065457.GA12837@fluxcoil.net> Message-ID: <20100512172828.GA13768@fluxcoil.net> On Wed, May 12, 2010 at 12:24:00PM -0500, Rob Townley wrote: > > Yes, it is a machine level as opposed to user level vpn. tinc would > have to run all machines to make it the easiest to use. With freeipa, > that could be easy. > > The keys currently are RSA public / private keypairs. > > Does not have existing code to work with ldap / kerberos as far as i know. Thanks a bunch for clearing up, Christian From rob.townley at gmail.com Wed May 12 17:24:00 2010 From: rob.townley at gmail.com (Rob Townley) Date: Wed, 12 May 2010 12:24:00 -0500 Subject: [Freeipa-users] Give laptops bidirectional anywhere access to freeipa and /home/ In-Reply-To: <20100512065457.GA12837@fluxcoil.net> References: <20100512065457.GA12837@fluxcoil.net> Message-ID: The main difference between tinc vpns and traditional vpns is that tinc is bidirectional and does not require the user to enter a username password. So if the computer is turned on, the remote machine is reachable by the IT department. If it is a windows machine, you may want to verify antivirus signatures are up-to-date. FusionInventory could be used to push software. Yes, it is a machine level as opposed to user level vpn. tinc would have to run all machines to make it the easiest to use. With freeipa, that could be easy. The keys currently are RSA public / private keypairs. Does not have existing code to work with ldap / kerberos as far as i know. On 5/12/10, Christian Horn wrote: > On Tue, May 11, 2010 at 04:42:26PM -0500, Rob Townley wrote: >> Microsoft is touting "Direct Access" as a main reason to upgrade to >> Win2008R2 / Win7. > > All i see there functionalitywise can be provided by a vpn-endpoint > using kerberos/ldap for authentication/authorization. > > As a feature i read 'use homeshare without using the vpn' but in the > end its just 'using a remote filesystem using the computer principal > for authentication'. > > >> HOW: >> Use existing cross platform tunneling and tap devices for LinMacWin - >> very well tested. Comes with tinc-vpn. >> tinc-vpn for the virtual IP addresses. These are secondary IP >> addresses all machines would have. >> dynamic dns port numbers stored in bind's SRV or TXT records for easy >> configuration. >> tinc-vpn keys stored in dns KEY record for key management. >> tinc-vpn can use IPv6 if needed. >> tinc-vpn for the encryption now, ipSec later? >> >> FreeIPA provides the centralized management infrastructure that >> tinc-vpn like solutions are missing. > > If tinc can already work using kerberos/ldap for authentication/au- > thorization then you could create a howto or maybe tinc-package with > the appropriate libraries. > This would then add vpn-endpoint functionality to freeipa. > > > Christian > From ssorce at redhat.com Wed May 12 19:04:35 2010 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 12 May 2010 15:04:35 -0400 Subject: [Freeipa-users] Give laptops bidirectional anywhere access to freeipa and /home/ In-Reply-To: References: <20100512065457.GA12837@fluxcoil.net> Message-ID: <20100512150435.5dc8fe3e@willson.li.ssimo.org> On Wed, 12 May 2010 12:24:00 -0500 Rob Townley wrote: > The main difference between tinc vpns and traditional vpns is that > tinc is bidirectional and does not require the user to enter a > username password. So if the computer is turned on, the remote > machine is reachable by the IT department. If it is a windows > machine, you may want to verify antivirus signatures are up-to-date. > FusionInventory could be used to push software. > > Yes, it is a machine level as opposed to user level vpn. tinc would > have to run all machines to make it the easiest to use. With freeipa, > that could be easy. > > The keys currently are RSA public / private keypairs. > > Does not have existing code to work with ldap / kerberos as far as i > know. Looks interesting, do you know what's the difference between tinc and something like openvpn ? Is it just the fact that tinc allows inbound connections, or is there more ? Simo. -- Simo Sorce * Red Hat, Inc * New York From dpal at redhat.com Wed May 12 21:38:08 2010 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 12 May 2010 17:38:08 -0400 Subject: [Freeipa-users] Give laptops bidirectional anywhere access to freeipa and /home/ In-Reply-To: References: <20100512065457.GA12837@fluxcoil.net> Message-ID: <4BEB1FC0.3000407@redhat.com> Rob Townley wrote: > The main difference between tinc vpns and traditional vpns is that > tinc is bidirectional and does not require the user to enter a > username password. So if the computer is turned on, the remote > machine is reachable by the IT department. If it is a windows > machine, you may want to verify antivirus signatures are up-to-date. > FusionInventory could be used to push software. > > Yes, it is a machine level as opposed to user level vpn. tinc would > have to run all machines to make it the easiest to use. With freeipa, > that could be easy. > > The keys currently are RSA public / private keypairs. > > Does not have existing code to work with ldap / kerberos as far as i know. > Would be great if it could leverage kerberos for this. Then it would have been really easy with IPA and no need for additional key management. Host keytabs are already managed by FreeIPA v2. But certmonger would be able to help with certs too. Have you looked at cernmonger as a provisioning tool for that sort of deployment? Again freeIPA v2 is capable of handling certs for this case too. -- Thank you, Dmitri Pal Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From rob.townley at gmail.com Thu May 13 08:34:59 2010 From: rob.townley at gmail.com (Rob Townley) Date: Thu, 13 May 2010 03:34:59 -0500 Subject: [Freeipa-users] Give laptops bidirectional anywhere access to freeipa and /home/ In-Reply-To: <4BEB1FC0.3000407@redhat.com> References: <20100512065457.GA12837@fluxcoil.net> <4BEB1FC0.3000407@redhat.com> Message-ID: On Wed, May 12, 2010 at 4:38 PM, Dmitri Pal wrote: > Rob Townley wrote: >> The main difference between tinc vpns and traditional vpns is that >> tinc is bidirectional and does not require the user to enter a >> username password. ?So if the computer is turned on, the remote >> machine is reachable by the IT department. ?If it is a windows >> machine, you may want to verify antivirus signatures are up-to-date. >> FusionInventory could be used to push software. >> >> Yes, it is a machine level as opposed to user level vpn. ?tinc would >> have to run all machines to make it the easiest to use. ?With freeipa, >> that could be easy. >> >> The keys currently are RSA public / private keypairs. >> >> Does not have existing code to work with ldap / kerberos as far as i know. >> > > Would be great if it could leverage kerberos for this. > Then it would have been really easy with IPA and no need for additional > key management. > Host keytabs are already managed by FreeIPA v2. > But certmonger would be able to help with certs too. > Have you looked at cernmonger as a provisioning tool for that sort of > deployment? > Again freeIPA v2 is capable of handling certs for this case too. Would love to see more kerberized services instead of ldapified services. But not clear how kerberos would fit in with tinc. When i think of kerberos, i think of ticket requests to a fleet of ticket granting servers which reply with a dual stamped ticket that both me and a less trusted third party can use for mutual auth. What i like about kerberized services is that i don't have to send my password to a less trusted third party like you do with LDAP (AFAIK - definitely not without user certificates). Because of this weakness of LDAP, i can't outsource our timetrex timeclock ldapified webserver and give employees single sign on because that would mean an untrusted third party would have all our passwords. A kerberized timetrex service could be enrolled with least privilege but still give employees sso and without sending a password to anything but a kdc. i love kerberos, but it isn't PKI by itself, it is tickets, so it isn't totally clear how the two work together, but i am sure freeipa provides that glue. I looked at certmonger and certmaster and from there looked at func. Looks like key management and local key storage can be done by the func platform and the vpn service could be one of the consumers of the func certificate platform. Central key management would be done by certmaster or freeipa. Looks promising, but none of the client side appears cross platform for the MacWin workstations. i thought nss or sss would be the crossplatform local key store. i have no idea if it is realistic to modify tinc to use gssapi / spnego, but i believe it then could get kerberos tickets and access to the same local certs and be crossplatform? One potential advantage of kerberos / ldap would be having different groups with different access levels to the other nodes. You say it would be easier for the key management if it was kerberized, what other advantages? > > > > -- > Thank you, > Dmitri Pal > > Engineering Manager IPA project, > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ > > From rob.townley at gmail.com Thu May 13 09:32:45 2010 From: rob.townley at gmail.com (Rob Townley) Date: Thu, 13 May 2010 04:32:45 -0500 Subject: [Freeipa-users] Give laptops bidirectional anywhere access to freeipa and /home/ In-Reply-To: <20100512150435.5dc8fe3e@willson.li.ssimo.org> References: <20100512065457.GA12837@fluxcoil.net> <20100512150435.5dc8fe3e@willson.li.ssimo.org> Message-ID: On Wed, May 12, 2010 at 2:04 PM, Simo Sorce wrote: > On Wed, 12 May 2010 12:24:00 -0500 > Rob Townley wrote: > >> The main difference between tinc vpns and traditional vpns is that >> tinc is bidirectional and does not require the user to enter a >> username password. ?So if the computer is turned on, the remote >> machine is reachable by the IT department. ?If it is a windows >> machine, you may want to verify antivirus signatures are up-to-date. >> FusionInventory could be used to push software. >> >> Yes, it is a machine level as opposed to user level vpn. ?tinc would >> have to run all machines to make it the easiest to use. ?With freeipa, >> that could be easy. >> >> The keys currently are RSA public / private keypairs. >> >> Does not have existing code to work with ldap / kerberos as far as i >> know. > > Looks interesting, do you know what's the difference between tinc and > something like openvpn ? Is it just the fact that tinc allows inbound > connections, or is there more ? Tinc is a peer-to-peer vpn in the class of the Hamachi, wippien - a jabberd, n2n from the ntop creators and others. p2p vpns can have a central server to register dynamic dns and nat port entries, and store public keys but traffic would not necessarily pass through a central server. -p2p vpns connect to multiple "servers" simultaneously in more of grid topology. Nodes can connect to multiple branch / home offices simultaneously and directly. Whereas OpenVPN is a star topology. All traffic must go through a single central vpn server. Yes, there can be more than one OpenVPN server, but the client can connect to only one at a time. -tinc is activated on boot up whether or not someone is logged in at the console. The default for vpnc / OpenVPN is for a user to enter a username / password. There are ways to automate the openvpn client logon (saved password?), but probably disconnected when no one has authenticated at the console. With tinc, IT gets remote access to the machine at any time. With OpenVPN, you may need to call the user at 3am to reconnect after windows automatic updates initiates a machine restart. -p2p vpns can be much closer to zero configuration which is important when there is not a full time IT staff. i see myself using tinc / freeipa / fusioninventory to administer remotely located family machines. i looked at OpenVPN.net again for the first time in a long time. It is so much more than it used to be, but i believe it still falls short. i am no expert on vpns. i know OpenVPN is a great product to many people and it may even be more secure in and of itself as a vpn product. But holistically, the biggest vulnerability to the entire infrastructure are the discontinously connected laptops. Patches are not applied because IT does not have access. tinc provides always on access, so remote machines can be updated. Of course, i am thinking of windows patch management insanity, not yum-updatesd bliss. - > > Simo. > > -- > Simo Sorce * Red Hat, Inc * New York > From dpal at redhat.com Thu May 13 12:46:25 2010 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 13 May 2010 08:46:25 -0400 Subject: [Freeipa-users] Give laptops bidirectional anywhere access to freeipa and /home/ In-Reply-To: References: <20100512065457.GA12837@fluxcoil.net> <4BEB1FC0.3000407@redhat.com> Message-ID: <4BEBF4A1.80705@redhat.com> Rob Townley wrote: > On Wed, May 12, 2010 at 4:38 PM, Dmitri Pal wrote: > >> Rob Townley wrote: >> >>> The main difference between tinc vpns and traditional vpns is that >>> tinc is bidirectional and does not require the user to enter a >>> username password. So if the computer is turned on, the remote >>> machine is reachable by the IT department. If it is a windows >>> machine, you may want to verify antivirus signatures are up-to-date. >>> FusionInventory could be used to push software. >>> >>> Yes, it is a machine level as opposed to user level vpn. tinc would >>> have to run all machines to make it the easiest to use. With freeipa, >>> that could be easy. >>> >>> The keys currently are RSA public / private keypairs. >>> >>> Does not have existing code to work with ldap / kerberos as far as i know. >>> >>> >> Would be great if it could leverage kerberos for this. >> Then it would have been really easy with IPA and no need for additional >> key management. >> Host keytabs are already managed by FreeIPA v2. >> But certmonger would be able to help with certs too. >> Have you looked at cernmonger as a provisioning tool for that sort of >> deployment? >> Again freeIPA v2 is capable of handling certs for this case too. >> > > Would love to see more kerberized services instead of ldapified > services. But not clear how kerberos would fit in with tinc. When i > think of kerberos, i think of ticket requests to a fleet of ticket > granting servers which reply with a dual stamped ticket that both me > and a less trusted third party can use for mutual auth. What i like > about kerberized services is that i don't have to send my password to > a less trusted third party like you do with LDAP (AFAIK - definitely > not without user certificates). Because of this weakness of LDAP, i > can't outsource our timetrex timeclock ldapified webserver and give > employees single sign on because that would mean an untrusted third > party would have all our passwords. A kerberized timetrex service > could be enrolled with least privilege but still give employees sso > and without sending a password to anything but a kdc. i love > kerberos, but it isn't PKI by itself, it is tickets, so it isn't > totally clear how the two work together, but i am sure freeipa > provides that glue. > > I looked at certmonger and certmaster and from there looked at func. > Looks like key management and local key storage can be done by the > func platform and the vpn service could be one of the consumers of the > func certificate platform. Central key management would be done by > certmaster or freeipa. Looks promising, but none of the client side > appears cross platform for the MacWin workstations. i thought nss or > sss would be the crossplatform local key store. > > i have no idea if it is realistic to modify tinc to use gssapi / > spnego, but i believe it then could get kerberos tickets and access to > the same local certs and be crossplatform? One potential advantage of > kerberos / ldap would be having different groups with different access > levels to the other nodes. You say it would be easier for the key > management if it was kerberized, what other advantages? > > If/when the tinc is kerberized then the following sequence of operations would happen: The client side of the VPN connection tries to connect to the server side of the VPN connection. Both sides are assumed to be manged hosts in the same enterprise. They both are managed by IPA and have a keytab provision to them and belong to the same kerberos realm (same IPA domain). The server side of the VPN connection will reguire client to present a ticket destined for that service. The client side would have to request that ticket from KDC. So the client will first acquire so called TGT (ticket granting ticket) using keytab (machine password). As soon as client has TGT it can be used for several hours (usually 8 - 24) to acquire tickets to access other services (server side of the tinc connection). All this happens automatically behind the scenes and implemented by the kerberos libraries. Tinc just needs to implement GSS API (which is a complex API but still...) This is the main advantage - no need to deal with the PKI infrastructure, cert provisioning etc. But of cause it is written with Linux laptops in mind. With Windows this will be more complex and IPA is not there yet to handle native windows clients. There are ways to configure windows machines to be a part of the Kerberos realm and thus IPA but I am not sure if you would want to go this route. >> >> -- >> Thank you, >> Dmitri Pal >> >> Engineering Manager IPA project, >> Red Hat Inc. >> >> >> ------------------------------- >> Looking to carve out IT costs? >> www.redhat.com/carveoutcosts/ >> >> >> > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > > > -- Thank you, Dmitri Pal Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From krzysztof.zajac at artegence.com Tue May 25 13:28:14 2010 From: krzysztof.zajac at artegence.com (=?UTF-8?B?S3J6eXN6dG9mIFphasSFYw==?=) Date: Tue, 25 May 2010 15:28:14 +0200 Subject: [Freeipa-users] problem with build rpm package of freeipa-server for centos Message-ID: <4BFBD06E.1000509@artegence.com> Hi, I have to build freeipa package for centos server. I've downloaded *.src.rpm file but after rpmbuild -ba command I receive the following error: tg-admin i18n compile Traceback (most recent call last): File "/usr/bin/tg-admin", line 5, in ? from pkg_resources import load_entry_point File "/usr/lib/python2.4/site-packages/pkg_resources.py", line 2479, in ? working_set.require(__requires__) File "/usr/lib/python2.4/site-packages/pkg_resources.py", line 585, in require needed = self.resolve(parse_requirements(requirements)) File "/usr/lib/python2.4/site-packages/pkg_resources.py", line 483, in resolve raise DistributionNotFound(req) # XXX put more info here pkg_resources.DistributionNotFound: Cheetah>=2.0.1 make[4]: *** [locales/ja/LC_MESSAGES/messages.mo] Error 1 make[4]: Leaving directory `/home/kzajac/rpmbuild/BUILD/freeipa-1.2.2/ipa-server/ipa-gui' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/home/kzajac/rpmbuild/BUILD/freeipa-1.2.2/ipa-server/ipa-gui' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/kzajac/rpmbuild/BUILD/freeipa-1.2.2/ipa-server' make[1]: *** [all] Error 2 make[1]: Leaving directory `/home/kzajac/rpmbuild/BUILD/freeipa-1.2.2/ipa-server' make: *** [all] Error 1 error: Bad exit status from /var/tmp/rpm-tmp.88078 (%build) -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Tue May 25 18:57:19 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 25 May 2010 14:57:19 -0400 Subject: [Freeipa-users] problem with build rpm package of freeipa-server for centos In-Reply-To: <4BFBD06E.1000509@artegence.com> References: <4BFBD06E.1000509@artegence.com> Message-ID: <4BFC1D8F.8020404@redhat.com> Krzysztof Zaj?c wrote: > Hi, > > I have to build freeipa package for centos server. I've downloaded > *.src.rpm file but after rpmbuild -ba command I receive the following > error: > > tg-admin i18n compile > Traceback (most recent call last): > File "/usr/bin/tg-admin", line 5, in ? > from pkg_resources import load_entry_point > File "/usr/lib/python2.4/site-packages/pkg_resources.py", line 2479, in ? > working_set.require(__requires__) > File "/usr/lib/python2.4/site-packages/pkg_resources.py", line 585, in > require > needed = self.resolve(parse_requirements(requirements)) > File "/usr/lib/python2.4/site-packages/pkg_resources.py", line 483, in > resolve > raise DistributionNotFound(req) # XXX put more info here > pkg_resources.DistributionNotFound: Cheetah>=2.0.1 > make[4]: *** [locales/ja/LC_MESSAGES/messages.mo] Error 1 > make[4]: Leaving directory > `/home/kzajac/rpmbuild/BUILD/freeipa-1.2.2/ipa-server/ipa-gui' > make[3]: *** [all-recursive] Error 1 > make[3]: Leaving directory > `/home/kzajac/rpmbuild/BUILD/freeipa-1.2.2/ipa-server/ipa-gui' > make[2]: *** [all-recursive] Error 1 > make[2]: Leaving directory > `/home/kzajac/rpmbuild/BUILD/freeipa-1.2.2/ipa-server' > make[1]: *** [all] Error 2 > make[1]: Leaving directory > `/home/kzajac/rpmbuild/BUILD/freeipa-1.2.2/ipa-server' > make: *** [all] Error 1 > error: Bad exit status from /var/tmp/rpm-tmp.88078 (%build) > I'm not entirely sure, it seems like you're missing something though. This was seen once before that I know of and we didn't get a follow-up if there was a fix: http://www.mail-archive.com/freeipa-users at redhat.com/msg00383.html Do you have python-cheetah installed? rob From ssorce at redhat.com Wed May 26 12:23:42 2010 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 26 May 2010 08:23:42 -0400 Subject: [Freeipa-users] Give laptops bidirectional anywhere access to freeipa and /home/ In-Reply-To: References: <20100512065457.GA12837@fluxcoil.net> <20100512150435.5dc8fe3e@willson.li.ssimo.org> <20100514082623.1734e282@willson.li.ssimo.org> Message-ID: <20100526082342.2330cc88@willson.li.ssimo.org> On Wed, 26 May 2010 03:40:33 -0500 Rob Townley wrote: > Tinc does not have a common shared secret between peers but that would > probably be an improvement to make it more like the hamachi vpn. If > both nodes do not have each other's public key host file, they should > not be able to communicate when tinc is in strict mode. In order to > receive something from another tinc node, you would need to trick the > remote node into getting your tinc host key file. Probably not all > that hard of a trick, but a good reason to have central management of > a mesh network. > > Tinc-vpn does not use a Certificate Authority nor X.509, so that is a > weakness of tinc on a large scale. Each tinc node uses a host > text file containing a RSA public key that needs to be distributed > manually to each node if using a strict (tinc version 1.13) > connection configuration. The mesh nature in a less strict / less > secure config allows nodes to connect to other nodes that it does not > have a public certificate for by connecting to an intermediate node. > > A central management point such as available in freeIPA or > ocsinventory-ng would make tinc more favorable. If tinc used kerberos as an optional authentication method then it would not even need the additional RSA public/private key pairs. All it would need is to have a host keytab and access to the FreeIPA server to get a ticket for the other machine. At that point you have mutual authentication and blessing from the KDC. The only downside is that p2p connection wouldn't work if the central server is not reachable at all, but that's probably ok. Anyway, this is a very interesting idea, if someone wants to play with it I am willing to lend a hand to help the effort. Although at the moment we do not have time/resources to start an effort on our own, we may reconsider this after we get 2.0 out of the door. Simo. -- Simo Sorce * Red Hat, Inc * New York From sailer at sailer.dynip.lugs.ch Wed May 26 18:09:16 2010 From: sailer at sailer.dynip.lugs.ch (Thomas Sailer) Date: Wed, 26 May 2010 20:09:16 +0200 Subject: [Freeipa-users] NFS4 after client upgrade to Fedora 13 Message-ID: <1274897356.4428.4.camel@xbox360.hq.axsem.com> Hi, After upgrading one IPA client from Fedora12 to Fedora13 (the server runs Fedora12), I'm experiencing NFS4 problems. I can still mount the server from the client like this: mount -t nfs4 -o soft,intr,rsize=8192,wsize=8192,rw,sec=krb5p server.xxx.com:/home /tmp/z root can then successfully list subdirectories with ls /tmp/z. However, when a normal user tries to do this, he gets -EACCES. Permissions of /tmp/z should be ok: # ls -ldZ /tmp/z drwxr-xr-x. root root system_u:object_r:nfs_t:s0 /tmp/z # getfacl /tmp/z getfacl: Removing leading '/' from absolute path names # file: tmp/z # owner: root # group: root user::rwx group::r-x other::r-x # nfs4_getfacl /tmp/z A::OWNER@:rwaDxtTcCy A::GROUP@:rxtcy A::EVERYONE@:rxtcy It worked under Fedora 12. Does anybody have an idea what went wrong? Thanks, Tom From rcritten at redhat.com Thu May 27 13:09:16 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 27 May 2010 09:09:16 -0400 Subject: [Freeipa-users] NFS4 after client upgrade to Fedora 13 In-Reply-To: <1274897356.4428.4.camel@xbox360.hq.axsem.com> References: <1274897356.4428.4.camel@xbox360.hq.axsem.com> Message-ID: <4BFE6EFC.6000705@redhat.com> Thomas Sailer wrote: > Hi, > > After upgrading one IPA client from Fedora12 to Fedora13 (the server > runs Fedora12), I'm experiencing NFS4 problems. > > I can still mount the server from the client like this: > mount -t nfs4 -o soft,intr,rsize=8192,wsize=8192,rw,sec=krb5p server.xxx.com:/home /tmp/z > root can then successfully list subdirectories with ls /tmp/z. However, > when a normal user tries to do this, he gets -EACCES. > > Permissions of /tmp/z should be ok: > > # ls -ldZ /tmp/z > drwxr-xr-x. root root system_u:object_r:nfs_t:s0 /tmp/z > > # getfacl /tmp/z > getfacl: Removing leading '/' from absolute path names > # file: tmp/z > # owner: root > # group: root > user::rwx > group::r-x > other::r-x > > # nfs4_getfacl /tmp/z > A::OWNER@:rwaDxtTcCy > A::GROUP@:rxtcy > A::EVERYONE@:rxtcy > > It worked under Fedora 12. Does anybody have an idea what went wrong? > I assume the keytab is still valid since the mount succeeds and root works. Kerberos otherwise works ok on this machine, you can kinit, etc? You might want to check the kdc log on and the 389-ds log, you might see some querying to find the user for authentication. Do things like 'getent passwd ' still work? rob From sailer at sailer.dynip.lugs.ch Thu May 27 14:24:09 2010 From: sailer at sailer.dynip.lugs.ch (Thomas Sailer) Date: Thu, 27 May 2010 16:24:09 +0200 Subject: [Freeipa-users] NFS4 after client upgrade to Fedora 13 In-Reply-To: <4BFE6EFC.6000705@redhat.com> References: <1274897356.4428.4.camel@xbox360.hq.axsem.com> <4BFE6EFC.6000705@redhat.com> Message-ID: <1274970249.4428.40.camel@xbox360.hq.axsem.com> On Thu, 2010-05-27 at 09:09 -0400, Rob Crittenden wrote: > I assume the keytab is still valid since the mount succeeds and root > works. Kerberos otherwise works ok on this machine, you can kinit, etc? Hm, the server didn't change, and on the client klist -k /etc/krb5.keytab -e does not suggest anything changed, so yes the keytab seems to be ok. Kerberos works as well. > You might want to check the kdc log on and the 389-ds log, you might see > some querying to find the user for authentication. Neither /var/log/krb5kdc.log nor /var/log/dirsrv/slapd-XXX-COM/errors lists anything related to that client. > Do things like 'getent passwd ' still work? Yes. I don't think it's anything related to the server, or krb5 on the client going wrong. At the time the non-root user does ls /tmp/z, there is no network traffic, so the server cannot even know that some user tries to ls the mount directory. Also, I've monitored the network traffic with wireshark, the whole NFSv4 exchange seems to work as expected (unfortunately wireshark does not seem to have a dissector for V4 composite RPC calls, so I don't know in detail what server and client are talking about), I have not seen any GSS related failures in the protocol exchange. I've tried selective downgrade of the client. I've downgraded kernel, nfs-utils*, cyrus-sasl*, libtirpc*, krb5*, so far without success. I've also tried the opposite, i.e. selectively upgrading a working fc12 client, so far without any insight, it is still working. I've upgraded the following packages: grubby-7.0.13-1.fc13.x86_64 kernel-2.6.33.4-95.fc13.x86_64 krb5-devel-1.7.1-10.fc13.x86_64 krb5-libs-1.7.1-10.fc13.i686 krb5-libs-1.7.1-10.fc13.x86_64 krb5-workstation-1.7.1-10.fc13.x86_64 linux-firmware-20100106-4.fc13.noarch nfs-utils-1.2.2-2.fc13.x86_64 nfs-utils-lib-1.1.5-1.fc13.x86_64 I'm a bit at a loss... Tom From ssorce at redhat.com Thu May 27 16:27:49 2010 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 27 May 2010 12:27:49 -0400 Subject: [Freeipa-users] NFS4 after client upgrade to Fedora 13 In-Reply-To: <1274897356.4428.4.camel@xbox360.hq.axsem.com> References: <1274897356.4428.4.camel@xbox360.hq.axsem.com> Message-ID: <20100527122749.46853184@willson.li.ssimo.org> On Wed, 26 May 2010 20:09:16 +0200 Thomas Sailer wrote: > Hi, > > After upgrading one IPA client from Fedora12 to Fedora13 (the server > runs Fedora12), I'm experiencing NFS4 problems. > > I can still mount the server from the client like this: > mount -t nfs4 -o soft,intr,rsize=8192,wsize=8192,rw,sec=krb5p > server.xxx.com:/home /tmp/z root can then successfully list > subdirectories with ls /tmp/z. However, when a normal user tries to > do this, he gets -EACCES. > > Permissions of /tmp/z should be ok: > > # ls -ldZ /tmp/z > drwxr-xr-x. root root system_u:object_r:nfs_t:s0 /tmp/z > > # getfacl /tmp/z > getfacl: Removing leading '/' from absolute path names > # file: tmp/z > # owner: root > # group: root > user::rwx > group::r-x > other::r-x > > # nfs4_getfacl /tmp/z > A::OWNER@:rwaDxtTcCy > A::GROUP@:rxtcy > A::EVERYONE@:rxtcy > > It worked under Fedora 12. Does anybody have an idea what went wrong? Tom, if you have only a DES key in your keytab for NFS (and you do if you used in in F12 as NFS supported only DES) then you probably see the effect of the new kerberos libraries disallowing DES. Try adding allow_weak_crypto = true to your krb5.conf or alternatively rekey your NFS credentials to add RC4/AES keys (rekeying works only if both client and server kernels supporting anything but DES, I think F13's kernels should have those patches now, but old kernels support only DES). Simo. -- Simo Sorce * Red Hat, Inc * New York From t.sailer at alumni.ethz.ch Thu May 27 17:13:47 2010 From: t.sailer at alumni.ethz.ch (Thomas Sailer) Date: Thu, 27 May 2010 19:13:47 +0200 Subject: [Freeipa-users] NFS4 after client upgrade to Fedora 13 In-Reply-To: <20100527122749.46853184@willson.li.ssimo.org> References: <1274897356.4428.4.camel@xbox360.hq.axsem.com> <20100527122749.46853184@willson.li.ssimo.org> Message-ID: <1274980427.4428.44.camel@xbox360.hq.axsem.com> On Thu, 2010-05-27 at 12:27 -0400, Simo Sorce wrote: > Try adding allow_weak_crypto = true to your krb5.conf or alternatively > rekey your NFS credentials to add RC4/AES keys (rekeying works only if > both client and server kernels supporting anything but DES, I think > F13's kernels should have those patches now, but old kernels support > only DES). Thanks for the hint! Unfortunately, it does not help. I've put allow_weak_crypto=true in the libdefaults section, but I still get permission denied when trying to access the mount directory as non-root. However, I got my rawhide machine connecting to the IPA server that way :) I think allow_weak_crypto is only necessary for krb5 1.8 and later, while F13 still has 1.7. Tom From ssorce at redhat.com Thu May 27 18:25:56 2010 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 27 May 2010 14:25:56 -0400 Subject: [Freeipa-users] NFS4 after client upgrade to Fedora 13 In-Reply-To: <20100527122749.46853184@willson.li.ssimo.org> References: <1274897356.4428.4.camel@xbox360.hq.axsem.com> <20100527122749.46853184@willson.li.ssimo.org> Message-ID: <20100527142556.0b1ed1cf@willson.li.ssimo.org> On Thu, 27 May 2010 12:27:49 -0400 Simo Sorce wrote: > Tom, apologies, I meant Thomas, not enough sleep I gues :/ Simo. -- Simo Sorce * Red Hat, Inc * New York From ssorce at redhat.com Thu May 27 18:30:41 2010 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 27 May 2010 14:30:41 -0400 Subject: [Freeipa-users] NFS4 after client upgrade to Fedora 13 In-Reply-To: <1274980427.4428.44.camel@xbox360.hq.axsem.com> References: <1274897356.4428.4.camel@xbox360.hq.axsem.com> <20100527122749.46853184@willson.li.ssimo.org> <1274980427.4428.44.camel@xbox360.hq.axsem.com> Message-ID: <20100527143041.6d1514e8@willson.li.ssimo.org> On Thu, 27 May 2010 19:13:47 +0200 Thomas Sailer wrote: > On Thu, 2010-05-27 at 12:27 -0400, Simo Sorce wrote: > > > Try adding allow_weak_crypto = true to your krb5.conf or > > alternatively rekey your NFS credentials to add RC4/AES keys > > (rekeying works only if both client and server kernels supporting > > anything but DES, I think F13's kernels should have those patches > > now, but old kernels support only DES). > > Thanks for the hint! Unfortunately, it does not help. I've put > allow_weak_crypto=true in the libdefaults section, but I still get > permission denied when trying to access the mount directory as > non-root. > > However, I got my rawhide machine connecting to the IPA server that > way :) > > I think allow_weak_crypto is only necessary for krb5 1.8 and later, > while F13 still has 1.7. Oh right, then I guess you need to look into syslog to see if you can find any other hint. does the gssd daemon log anything ? Simo. -- Simo Sorce * Red Hat, Inc * New York From ssorce at redhat.com Thu May 27 22:05:45 2010 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 27 May 2010 18:05:45 -0400 Subject: [Freeipa-users] NFS4 after client upgrade to Fedora 13 In-Reply-To: <1274997508.21089.4.camel@unreal.home.sailer.dynip.lugs.ch> References: <1274897356.4428.4.camel@xbox360.hq.axsem.com> <20100527122749.46853184@willson.li.ssimo.org> <1274980427.4428.44.camel@xbox360.hq.axsem.com> <20100527143041.6d1514e8@willson.li.ssimo.org> <1274997508.21089.4.camel@unreal.home.sailer.dynip.lugs.ch> Message-ID: <20100527180545.4aa75018@willson.li.ssimo.org> On Thu, 27 May 2010 23:58:28 +0200 Thomas Sailer wrote: > For some reason I have no clue about, it does not like my credentials > cache (/tmp/krb5cc_1591) when not run from the console. I suspect an SELinux issue in this case, because manually starting it will run it as unconfined. Can you check /var/log/audit/audit.log ? Simo. -- Simo Sorce * Red Hat, Inc * New York From sailer at sailer.dynip.lugs.ch Thu May 27 21:58:28 2010 From: sailer at sailer.dynip.lugs.ch (Thomas Sailer) Date: Thu, 27 May 2010 23:58:28 +0200 Subject: [Freeipa-users] NFS4 after client upgrade to Fedora 13 In-Reply-To: <20100527143041.6d1514e8@willson.li.ssimo.org> References: <1274897356.4428.4.camel@xbox360.hq.axsem.com> <20100527122749.46853184@willson.li.ssimo.org> <1274980427.4428.44.camel@xbox360.hq.axsem.com> <20100527143041.6d1514e8@willson.li.ssimo.org> Message-ID: <1274997508.21089.4.camel@unreal.home.sailer.dynip.lugs.ch> On Thu, 2010-05-27 at 14:30 -0400, Simo Sorce wrote: > Oh right, > then I guess you need to look into syslog to see if you can find any > other hint. > > does the gssd daemon log anything ? It can be made to talk, like this: rpc.gssd -f -vvvvvv -rrrrrr Messages at startup: Warning: rpcsec_gss library does not support setting debug level beginning poll At mount time: handling gssd upcall (/var/lib/nfs/rpc_pipefs/nfs/clnt35) handle_gssd_upcall: 'mech=krb5 uid=0 ' handling krb5 upcall (/var/lib/nfs/rpc_pipefs/nfs/clnt35) process_krb5_upcall: service is '' Full hostname for 'server.xxx.com' is 'server.xxx.com' Full hostname for 'client.xxx.com' is 'client.xxx.com' Key table entry not found while getting keytab entry for 'root/client.xxx.com at XXX.COM' Success getting keytab entry for 'nfs/client.xxx.com at XXX.COM' Successfully obtained machine credentials for principal 'nfs/client.xxx.com at XXX.COM' stored in ccache 'FILE:/tmp/krb5cc_machine_XXX.COM' INFO: Credentials in CC 'FILE:/tmp/krb5cc_machine_XXX.COM' are good until 1275168019 using FILE:/tmp/krb5cc_machine_XXX.COM as credentials cache for machine creds using environment variable to select krb5 ccache FILE:/tmp/krb5cc_machine_XXX.COM creating context using fsuid 0 (save_uid 0) creating tcp client for server server.xxx.com DEBUG: port already set to 2049 creating context with server nfs at server.xxx.com DEBUG: serialize_krb5_ctx: lucid version! prepare_krb5_rfc1964_buffer: serializing keys with enctype 4 and length 8 doing downcall handling gssd upcall (/var/lib/nfs/rpc_pipefs/nfs/clnt35) handle_gssd_upcall: 'mech=krb5 uid=1591 ' handling krb5 upcall (/var/lib/nfs/rpc_pipefs/nfs/clnt35) process_krb5_upcall: service is '' getting credentials for client with uid 1591 for server server.xxx.com CC file '/tmp/krb5cc_1591' being considered, with preferred realm 'XXX.COM' CC file '/tmp/krb5cc_1591'(user at XXX.COM) passed all checks and has mtime of 1274978851 CC file '/tmp/krb5cc_10000_lxXOef' being considered, with preferred realm 'XXX.COM' CC file '/tmp/krb5cc_10000_lxXOef' owned by 10000, not 1591 CC file '/tmp/krb5cc_machine_XXX.COM' being considered, with preferred realm 'XXX.COM' CC file '/tmp/krb5cc_machine_XXX.COM' owned by 0, not 1591 CC file '/tmp/krb5cc_10000_CG6m2Y' being considered, with preferred realm 'XXX.COM' CC file '/tmp/krb5cc_10000_CG6m2Y' owned by 10000, not 1591 using FILE:/tmp/krb5cc_1591 as credentials cache for client with uid 1591 for server server.xxx.com using environment variable to select krb5 ccache FILE:/tmp/krb5cc_1591 creating context using fsuid 1591 (save_uid 0) creating tcp client for server server.xxx.com DEBUG: port already set to 2049 creating context with server nfs at server.xxx.com DEBUG: serialize_krb5_ctx: lucid version! prepare_krb5_rfc1964_buffer: serializing keys with enctype 4 and length 8 doing downcall Now interestingly, the access works if rpc.gssd is started from the console! When I start it using "service rpc.gssd restart", it fails again, now with this in the log: beginning poll handling gssd upcall (/var/lib/nfs/rpc_pipefs/nfs/clnt47) handle_gssd_upcall: 'mech=krb5 uid=0 ' handling krb5 upcall (/var/lib/nfs/rpc_pipefs/nfs/clnt47) process_krb5_upcall: service is '' Full hostname for 'server.xxx.com' is 'server.xxx.com' Full hostname for 'client.xxx.com' is 'client.xxx.com' Key table entry not found while getting keytab entry for 'root/client.xxx.com at XXX.COM' Success getting keytab entry for 'nfs/client.xxx.com at XXX.COM' Successfully obtained machine credentials for principal 'nfs/client.xxx.com at XXX.COM' stored in ccache 'FILE:/tmp/krb5cc_machine_XXX.COM' INFO: Credentials in CC 'FILE:/tmp/krb5cc_machine_XXX.COM' are good until 1275169699 using FILE:/tmp/krb5cc_machine_XXX.COM as credentials cache for machine creds using environment variable to select krb5 ccache FILE:/tmp/krb5cc_machine_XXX.COM creating context using fsuid 0 (save_uid 0) creating tcp client for server server.xxx.com DEBUG: port already set to 2049 creating context with server nfs at server.xxx.com DEBUG: serialize_krb5_ctx: lucid version! prepare_krb5_rfc1964_buffer: serializing keys with enctype 4 and length 8 doing downcall handling gssd upcall (/var/lib/nfs/rpc_pipefs/nfs/clnt47) handle_gssd_upcall: 'mech=krb5 uid=1591 ' handling krb5 upcall (/var/lib/nfs/rpc_pipefs/nfs/clnt47) process_krb5_upcall: service is '' getting credentials for client with uid 1591 for server server.xxx.com CC file '/tmp/krb5cc_1591' being considered, with preferred realm 'XXX.COM' CC file '/tmp/krb5cc_1591' is expired or corrupt CC file '/tmp/krb5cc_10000_lxXOef' being considered, with preferred realm 'XXX.COM' CC file '/tmp/krb5cc_10000_lxXOef' owned by 10000, not 1591 CC file '/tmp/krb5cc_machine_XXX.COM' being considered, with preferred realm 'XXX.COM' CC file '/tmp/krb5cc_machine_XXX.COM' owned by 0, not 1591 CC file '/tmp/krb5cc_10000_CG6m2Y' being considered, with preferred realm 'XXX.COM' CC file '/tmp/krb5cc_10000_CG6m2Y' owned by 10000, not 1591 WARNING: Failed to create krb5 context for user with uid 1591 for server server.xxx.com doing error downcall handling gssd upcall (/var/lib/nfs/rpc_pipefs/nfs/clnt47) handle_gssd_upcall: 'mech=krb5 uid=1591 ' handling krb5 upcall (/var/lib/nfs/rpc_pipefs/nfs/clnt47) process_krb5_upcall: service is '' getting credentials for client with uid 1591 for server server.xxx.com CC file '/tmp/krb5cc_1591' being considered, with preferred realm 'XXX.COM' CC file '/tmp/krb5cc_1591' is expired or corrupt CC file '/tmp/krb5cc_10000_lxXOef' being considered, with preferred realm 'XXX.COM' CC file '/tmp/krb5cc_10000_lxXOef' owned by 10000, not 1591 CC file '/tmp/krb5cc_machine_XXX.COM' being considered, with preferred realm 'XXX.COM' CC file '/tmp/krb5cc_machine_XXX.COM' owned by 0, not 1591 CC file '/tmp/krb5cc_10000_CG6m2Y' being considered, with preferred realm 'XXX.COM' CC file '/tmp/krb5cc_10000_CG6m2Y' owned by 10000, not 1591 WARNING: Failed to create krb5 context for user with uid 1591 for server server.xxx.com doing error downcall handling gssd upcall (/var/lib/nfs/rpc_pipefs/nfs/clnt47) handle_gssd_upcall: 'mech=krb5 uid=1591 ' handling krb5 upcall (/var/lib/nfs/rpc_pipefs/nfs/clnt47) process_krb5_upcall: service is '' getting credentials for client with uid 1591 for server server.xxx.com CC file '/tmp/krb5cc_1591' being considered, with preferred realm 'XXX.COM' CC file '/tmp/krb5cc_1591' is expired or corrupt CC file '/tmp/krb5cc_10000_lxXOef' being considered, with preferred realm 'XXX.COM' CC file '/tmp/krb5cc_10000_lxXOef' owned by 10000, not 1591 CC file '/tmp/krb5cc_machine_XXX.COM' being considered, with preferred realm 'XXX.COM' CC file '/tmp/krb5cc_machine_XXX.COM' owned by 0, not 1591 CC file '/tmp/krb5cc_10000_CG6m2Y' being considered, with preferred realm 'XXX.COM' CC file '/tmp/krb5cc_10000_CG6m2Y' owned by 10000, not 1591 WARNING: Failed to create krb5 context for user with uid 1591 for server server.xxx.com doing error downcall For some reason I have no clue about, it does not like my credentials cache (/tmp/krb5cc_1591) when not run from the console. Thanks, Tom From t.sailer at alumni.ethz.ch Thu May 27 22:27:00 2010 From: t.sailer at alumni.ethz.ch (Thomas Sailer) Date: Fri, 28 May 2010 00:27:00 +0200 Subject: [Freeipa-users] NFS4 after client upgrade to Fedora 13 In-Reply-To: <20100527143041.6d1514e8@willson.li.ssimo.org> References: <1274897356.4428.4.camel@xbox360.hq.axsem.com> <20100527122749.46853184@willson.li.ssimo.org> <1274980427.4428.44.camel@xbox360.hq.axsem.com> <20100527143041.6d1514e8@willson.li.ssimo.org> Message-ID: <1274999220.21089.13.camel@unreal.home.sailer.dynip.lugs.ch> Found it. It was selinux related. For some reason allow_gssd_read_tmp was off; running semanage boolean -1 allow_gssd_read_tmp solved it. [As a side note: why is this even tunable? Is there a practical usage mode of rpc.gssd that does not require access to the credential caches?] Thanks again for your help! Tom From sailer at sailer.dynip.lugs.ch Thu May 27 22:36:40 2010 From: sailer at sailer.dynip.lugs.ch (Thomas Sailer) Date: Fri, 28 May 2010 00:36:40 +0200 Subject: [Freeipa-users] NFS4 after client upgrade to Fedora 13 In-Reply-To: <20100527180545.4aa75018@willson.li.ssimo.org> References: <1274897356.4428.4.camel@xbox360.hq.axsem.com> <20100527122749.46853184@willson.li.ssimo.org> <1274980427.4428.44.camel@xbox360.hq.axsem.com> <20100527143041.6d1514e8@willson.li.ssimo.org> <1274997508.21089.4.camel@unreal.home.sailer.dynip.lugs.ch> <20100527180545.4aa75018@willson.li.ssimo.org> Message-ID: <1274999800.21089.14.camel@unreal.home.sailer.dynip.lugs.ch> On Thu, 2010-05-27 at 18:05 -0400, Simo Sorce wrote: > I suspect an SELinux issue in this case, because manually starting it > will run it as unconfined. > Can you check /var/log/audit/audit.log ? It's not in the audit log. The only gss related line in the audit log I could find is me changing the selinux bool: type=MAC_CONFIG_CHANGE msg=audit(1274998390.797:411): bool=allow_gssd_read_tmp val=1 old_val=0 auid=0 ses=45 Tom From sgros at zemris.fer.hr Fri May 28 15:02:12 2010 From: sgros at zemris.fer.hr (Stjepan Gros) Date: Fri, 28 May 2010 17:02:12 +0200 Subject: [Freeipa-users] Dynamic DNS and Kerberos... Message-ID: <1275058932.23651.6.camel@fedora.sistemnet.local> Hi! I have a simple question regarding adding hosts in Kerberos when hosts are dynamically assigned IP addresses and registered to DNS. In such cases, ipa-addservice complains that host has to have A record in DNS and doesn't want to add new principal. So, there are two choices: 1. temporarily add DNS records, run ipa-addservice, and remove DNS records, or 2. connect PC to network in order for host to receive IP address and registers with DNS, and then run ipa-addservice Unfortunatelly, my situation is such that option 2 isn't possible, and option 1 seems more like a hack than something systematic. So, is there a third option? Stjepan From rcritten at redhat.com Fri May 28 15:11:52 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 28 May 2010 11:11:52 -0400 Subject: [Freeipa-users] Dynamic DNS and Kerberos... In-Reply-To: <1275058932.23651.6.camel@fedora.sistemnet.local> References: <1275058932.23651.6.camel@fedora.sistemnet.local> Message-ID: <4BFFDD38.9000806@redhat.com> Stjepan Gros wrote: > Hi! > > I have a simple question regarding adding hosts in Kerberos when hosts > are dynamically assigned IP addresses and registered to DNS. In such > cases, ipa-addservice complains that host has to have A record in DNS > and doesn't want to add new principal. > > So, there are two choices: > > 1. temporarily add DNS records, run ipa-addservice, and remove DNS > records, or > > 2. connect PC to network in order for host to receive IP address and > registers with DNS, and then run ipa-addservice > > Unfortunatelly, my situation is such that option 2 isn't possible, and > option 1 seems more like a hack than something systematic. > > So, is there a third option? > > Stjepan Try the --force flag with ipa-addservice. It allows it to continue past DNS problems. rob