Re: [Freeipa-users] connecting freeipa server with free radius
On 08/24/2009 12:07 PM, Rachid Zarouali wrote: hello :) does anyone has successfully connected freeipa server with a radius server ? if so , is there any howto/doc? that may help me doing it myself ? Supporting radius is on our roadmap, but won't likely be part of v2. Our plan is to use FreeRADIUS. Connecting IPA and FreeRADIUS in a basic configuration is not difficult if all you want to do is PAP (just enable the krb5 module). However supporting 802.1 as well as Windows supplicants is likely to require some work on our end. There is also the issue of Web GUI support for radius management and desirable features such as group membership tests, time of day authorization, authorization based on NAS type and location (e.g. VPN vs. wireless, etc.), revocation of access (CoA), bandwidth controls, etc. These complications are reasons why Radius is lower on our priority list. However, one thing which will help us is getting a better understanding of out the hundreds of ways radius can be deployed and managed which are the ones are most important to support. What do you want in terms of radius support from IPA? Would you be willing to contribute to this area? -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] connecting freeipa server with free radius
On 08/26/2009 04:16 AM, Rachid Zarouali wrote: Hello Dimitri, I'll try to answer your questions the best i can :-) Basically we plain to use the ldap ipa password. at first we want to use radius for authentication only. i'm not sure about what you call outer/inner methods :( the base of the authentication is the project is the ipa ldap on which we try to connect a freeradius server which is used to authenticate admin's on router/firewall . am i clear ? If it's just admin access on a router/firewall I don't see a problem at the moment. You should be able to use PAP on the router/firewall, it encrypts the plaintext password and sends it to the freeradius server which decrypts resulting in the plaintext password. The freeradius server would then be configured to use Kerberos, it uses the plaintext password and obtains a TGT (i.e. it does a kinit on behalf of the user) if this is successful the radius authentication is successful. All this should work "out of the box" for both IPA and FreeRADIUS (although you'll have to edit the FreeRADIUS config to enable krb5). We're not thrilled with this solution because the radius server sees a plaintext password (although it's encrypted during transport). The security is adequate but not ideal. Safer authentication methods require us to do more integration work between IPA and FreeRADIUS, which at the moment is a deferred work item. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] deploying FreeIPA
On 12/12/2009 12:50 AM, jose mora wrote: hello how is everyone doing? I do have a request, can you help me Deploying FreeIPA? I would apreciate any kind of help thank you for your time Jose Mora We would like to help you but first you need to tell us what you need help with. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Web admin for FreeIPA Directory Server
On 01/27/2010 12:44 AM, Michael Kang wrote: Nobody answers my question: Could I ues phpLDAPadmin to maintain FreeIPA Directory Server? What would you like to administer? FreeIPA comes with a Web GUI that gives you an administrator interface for many operations. The 389 Directory server (which FreeIPA is based on) also comes with a Java based web administration interface, although we don't use it. There is no inherent reason you couldn't use phpLDAPadmin provided it supports the authentication we require. But more to the point is why? If there is something fundamentally lacking in the administration interface we provide we should fix it. Please note that v2 of FreeIPA has been under heavy development and the web GUI has received a lot of attention for the next release and whatever you're missing might have already been taken care of. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] Calling for translation help
Are you multilingual? Would you like to contribute to the FreeIPA project by providing translations? If so we could use your help! We just recently added FreeIPA to the Transifex.net translation portal. You can register yourself as a translator on Transifex.net, select a language of your choice and go to the FreeIPA project area in Transifex.net and provide translations for FreeIPA. The FreeIPA project area is: https://www.transifex.net/projects/p/freeipa/c/master We will include your translations in a future release and credit you for your contribution. For more information about Transifex, how to sign up and how to contribute please start with the Transifex main page: https://www.transifex.net Thank you for your help! The FreeIPA team. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] IPA roadmap
On 04/20/2010 11:27 AM, Tom Brown wrote: Can i ask what the future of (free-)IPA is please - I am very keen to get it in the door here and i thought that it was being actively but i have heard that there are no full time developers working on this at RH. Is this a product thats going to go away or is it something that is worth us investing our time in ? As Mark Twain said ""The reports of my death are greatly exaggerated". Any assertion that IPA is dead, dying, or in ill health are completely fallacious. We have about half a dozen RH developers working full time on IPA. We are currently working on version 2.0 of FreeIPA and we've been releasing test releases. IPA 2.0 is due to ship in RHEL 6.1. We are alive, well, and very much kicking :-) -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Reports and questions
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/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Feature request: TACACS+ integration
On 08/24/2010 11:22 PM, david klein wrote: Sorry to those who have already seen this; I posted to the wrong mailing list (the -interest mailing list instead of the -users list). As an NMS engineer, I have a use for integrated TACACS+ with a unified identity solution, so that the same account name and password can grant access for managing network infrastructure devices as well as UNIX and Linux servers, and so that network rights can be assigned and delegated through the same GUI as systems rights. There is an open source TACACS+ service called "tac_plus", which used to be maintained by Cisco, and which is now maintained by Shrubbery Networks, Inc (http://www.shrubbery.net/tac_plus/). It appears that under Shrubbery's guidance and development, the tac_plus daemon can use LDAP by way of PAM to handle authentication, according to http://www.shrubbery.net/tac_plus/PAM_guide.txt. At this point, only authentication appears to have been externalized, but it does prove the concept. How does Redhat currently measure the degree of interest in possible features for inclusion in the FreeIPA/EnterpriseIPA product, and would it be worthwhile to gather statements from other systems administrators to help demonstrate the desirability and usefulness of this feature request? This would be a very helpful capability, as it would remove dependence on ACS, which is expensive and complex (and complicated) TACACS+ server. This is the first request I've seen for TACAS support. Since IPA is a unified identity solution at it's core it's not clear to me at the moment what advantage there would be to TACAS other than as emulating a TACAS server for legacy and/or 3rd party products which depend on the TACAS protocol. If one wants to set up a TACAS daemon there is a reasonable chance it could validate against IPA (more investigation would be needed) and this would give you something which provide TACAS protocol but be backed by IPA and it's management tools. We do have plans on our roadmap to support RADIUS which is often used as an alternative to TACAS. But perhaps I haven't fully understood your request. So let me rephrase it and see if I have it correct. You want something on your network which speaks the TACAS+ protocol but whose identity management is backed by our IPA server. Is that correct? -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Feature request: TACACS+ integration
On 08/25/2010 08:21 AM, david klein wrote: On Wed, Aug 25, 2010 at 6:50 AM, John Dennis wrote: On 08/24/2010 11:22 PM, david klein wrote: Sorry to those who have already seen this; I posted to the wrong mailing list (the -interest mailing list instead of the -users list). As an NMS engineer, I have a use for integrated TACACS+ with a unified identity solution, so that the same account name and password can grant access for managing network infrastructure devices as well as UNIX and Linux servers, and so that network rights can be assigned and delegated through the same GUI as systems rights. There is an open source TACACS+ service called "tac_plus", which used to be maintained by Cisco, and which is now maintained by Shrubbery Networks, Inc (http://www.shrubbery.net/tac_plus/). It appears that under Shrubbery's guidance and development, the tac_plus daemon can use LDAP by way of PAM to handle authentication, according to http://www.shrubbery.net/tac_plus/PAM_guide.txt. At this point, only authentication appears to have been externalized, but it does prove the concept. How does Redhat currently measure the degree of interest in possible features for inclusion in the FreeIPA/EnterpriseIPA product, and would it be worthwhile to gather statements from other systems administrators to help demonstrate the desirability and usefulness of this feature request? This would be a very helpful capability, as it would remove dependence on ACS, which is expensive and complex (and complicated) TACACS+ server. This is the first request I've seen for TACAS support. Since IPA is a unified identity solution at it's core it's not clear to me at the moment what advantage there would be to TACAS other than as emulating a TACAS server for legacy and/or 3rd party products which depend on the TACAS protocol. If one wants to set up a TACAS daemon there is a reasonable chance it could validate against IPA (more investigation would be needed) and this would give you something which provide TACAS protocol but be backed by IPA and it's management tools. We do have plans on our roadmap to support RADIUS which is often used as an alternative to TACAS. But perhaps I haven't fully understood your request. So let me rephrase it and see if I have it correct. You want something on your network which speaks the TACAS+ protocol but whose identity management is backed by our IPA server. Is that correct? -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From both a network and a security point of view, TACACS+ is considered preferable to RADIUS; among other benefits, it enciphers the entire conversation, rather than just portions of it, and can provide more fine-grain authorization than RADIUS. Most Cisco shops I've encountered consider RADIUS to be an unacceptable solution for AAA. Cisco considers use of TACACS+ a best practice for AAA. What I am looking for is a device on the network which provides AAA facilities to network infrastructure devices, and which allows provisioning of network infrastructure credentials through the same interface and at the same time as systems credentials, and which keeps those credentials synchronized. O.K. fair enough. However TACACS is not on our roadmap. If you can demonstrate strong need by enterprise customers for TACACS it would be taken into consideration for a future version of the product. The more practical solution which may be available to you would be to avail yourself of the PAM integration in the tac_plus project (but to be honest I don't see how that would give you any of the sophisticated features you cite as being a prime motivator for utilization of TACACS). FreeIPA is an open source project and from what you say so is tac_plus. I would imagine patches would be welcomed by both projects which would allow the tac_plus daemon to utilize IPA as it's back end. We would be happy to answer any questions for the person(s) who wanted to undertake this and contribute their work. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Feature request: TACACS+ integration
On 08/25/2010 11:22 AM, James Roman wrote: The more practical solution which may be available to you would be to avail yourself of the PAM integration in the tac_plus project (but to be honest I don't see how that would give you any of the sophisticated features you cite as being a prime motivator for utilization of TACACS). FreeIPA is an open source project and from what you say so is tac_plus. I would imagine patches would be welcomed by both projects which would allow the tac_plus daemon to utilize IPA as it's back end. We would be happy to answer any questions for the person(s) who wanted to undertake this and contribute their work. From what I can see it looks like the missing piece would be the ability to look up tac_plus user->group assignments from the FreeIPA/389 LDAP server. It looks like tac_plus has ""integrated"" the authentication with LDAP via PAM, but not the authorization. When building an authentication solution for network devices with FreeIPA, providing authentication via TACACS+ would be secondary, since you could have your Cisco device directly authenticate the user against FreeIPA using Kerberos. TACACS+ primary benefit is in the granular control of Authorization to network device services. If you can get tac_plus to reference an LDAP server for group membership, then you might have a reasonable solution. You would still need to assign the group's network permissions in the tac_plus configuration file, but that would be done once. Once the group access was defined, you could assign LDAP users to groups that match what's in the tac_plus config file. This really requires the tac_plus team to code direct LDAP integration into their application similar to the way Freeradius can rely on an LDAP server as a back-end. The local PAM stack was not really intended to be a service that can be farmed out for other systems to use. It was meant as a way to provide access to local services running on that system. To use PAM for group membership (I.E. through the pam_listfile ACL) would require a separate tac_plus daemon and PAM configuration for each network device. Adding ldap queries to tac_plus would be the most general solution in which case this would have little direct relevance to IPA. However the schema we use, ACL's and internal "business logic" applied on top of LDAP queries might not map easily to a generic LDAP interface in tac_plus. I really don't know. All of this is to say there is another way to use IPA as a backend service besides connecting to our LDAP server. We do support an XML-RPC interface that is fully authenticated and encrypted. So another options would be for tac_plus to make RPC calls. Just a thought. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] hostMask attribute syntax issue in 60sudo.ldif
On 09/24/2010 03:53 PM, Dmitri Pal wrote: Brian LaMere wrote: On Fri, Sep 24, 2010 at 10:43 AM, Dmitri Palmailto:d...@redhat.com>> wrote: Brian LaMere wrote: > ah, odd - I'm used to IPs being IA5. then the equality match should > be changed? Can't have caseIgnoreIA5Match on a directory string :) Yes. This is what the patch does :-) so, out of curiousity...why 60sudo? Seems like a string matching netmask could be used more generically...it's redefined over as radiusFramedIPNetmask in 60radius.ldif. I go through and purge my tree of attributes I'll never need, sorry - I have strange quirks. See some discussion of the subject here: http://www.freeipa.org/page/SUDO_Schema_Design#Proposed_Schema under sudoHost. I tried to find something suitable but could not. I did not look at RADIUS though. Reusing core, well known attributes is a good practice since they are common. Relying on RADIUS schema to be present might be not. Yes we plan to support RADIUS in future but this work is deferred. FWIW, I have been in conversation with the upstream FreeRADIUS folks concerning the RADIUS ldap schema (In part because I just contributed code to store RADIUS clients (e.g. NAS's) in ldap) which included schema updates. During that discussion I pointed out how a number of the RADIUS attributes appeared to be incorrectly specified as IA5 strings and suggested the ldap schema should be updated to use UTF-8 instead (e.g. DirectoryString). There was buy-in this was the correct thing to do. However I don't specifically recall the status of the radiusFramedIPNetmask attribute. Anyway, all that is a long winded way of saying the use of IA5 appears to have been historic and incorrect in many schemas and there is an ongoing effort to fix the use of IA5. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] ipa-server-install fails
On 01/18/2011 04:32 PM, Corey Hemminger wrote: How do I add the updates-devel repo to fedora. I'm having issues with fedora 14 and ipa 2.0 beta 1 installing. I added the bleeding edge repo for ipa and updates-testing for fedora but I still get errors during the ca authority portion of the install. Corey Hi Corey: That doesn't give us much information to go on. Could you please tell us what the errors are? It would also help to know the versions of a couple of the key packages, e.g. $ rpm -q ipa-server-install pki-ca After you enabled the repos did you do a yum upgrade? To enable updates-devel edit /etc/yum.repos.d/fedora-updates.repo and make sure the enabled value is 1, e.g. enabled=1 -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] replica install failure....
On 03/29/2011 03:54 PM, Steven Jones wrote: Can you double-check that /etc/hosts is set up correctly? The ipv6 wasnt "right" I guess. I have added the host's name into that line.will retry. Hmm... last I knew the hosts file cannot be used for IPv6 addresses. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] CSV support in IPA administration tools - to be, or not to be?
On 01/10/2013 08:15 AM, Petr Spacek wrote: Hello, is there any user of CSV support built-in to IPA administration tools ("ipa" command)? Do you consider it sane or even useful? Please reply. I've always disliked our use of CSV values on both the command line and internally. They're just weird, nothing else in Unix works like this and as you point out below there are easier better alternatives. Plus with the use of CSV's there is a lot of awkward quoting in a variety of places. On the command line I always thought multiple values should be specified multiple times and internally they should be encapsulated in lists rather than parsing a CSV string (if it's logically a list then why isn't it a list?) However at this juncture I'm not sure we can make such a change, we have a published API that we would be violating. But perhaps we're not so far down the road we can't make such a change and we're better off doing it now while there is even a chance. It's not clear to me how much the command line is being used and specifically with CSV values. Do I think CSV's are sane and useful? No. Can we change that? That's a whole other story. I wanted to add single TXT record with double quotation marks (") inside the TXT data. I spent some time figuring out how it is supposed to work ... and with help of Petr^3 I managed to write the command. The resulting command (for BASH) is absolutely crazy: ipa dnsrecord-add example.test. newrec --txt-rec='"""created on 13:01:23"""' Do we really need support for this piece of insanity? Shells can do the same thing with much less pain :-) IPA with CSV support can add multiple attributes at once, e.g. ipa dnsrecord-add example.test. newrec --txt-rec=1,2,3,4,5,6,7,8,9 will add TXT records with value 1, 2, 3 etc. BASH can do the same thing (without the escaping hell): ipa dnsrecord-add example.test. newrec --txt-rec={1,2,3,4,5,6,7,8,9} and ipa dnsrecord-add example.test. newrec --txt-rec={1..9} BASH would expand to ipa dnsrecord-add example.test. newrec --txt-rec=1 --txt-rec=2 --txt-rec=3 --txt-rec=4 --txt-rec=5 --txt-rec=6 --txt-rec=7 --txt-rec=8 --txt-rec=9 -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] how do i apply patch?
On 01/11/2013 11:25 AM, Umarzuki Mochlis wrote: 2013/1/10 Martin Kosek : If you want to do a custom build, you can either use a fedpkg and create a scratch build of IPA with the patches applied or do a custom build from git tree. Using the fedpkg tool + build in koji may be the safest way to build such rpm that contain only the official build + chosen patches. Martin Hi, what I want to do is simply patch free ipa with that patch from ipa-server 2.2.0 on my centos 6 any method that would retain current configuration? You can do one of two things. 1) Download the source rpm matching the version you have installed, add the patch, rebuild the rpm locally, install the locally built rpm. 2) Apply the patch to the installed code, this is manual, there are opportunities to mess up a running system unless you're careful and it's not reproducible. But it can be faster and more expedient, most IPA devs do this all the time to try out potential fixes because it's so easy to edit installed Python code. However, if the patch in question depends on post install update run by the RPM install this won't (easily) work. The safest thing is option 1, build a patched RPM. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] CSV support in IPA administration tools - to be, or not to be?
On 01/11/2013 03:10 PM, Dmitri Pal wrote: On 01/10/2013 11:00 AM, John Dennis wrote: On 01/10/2013 08:15 AM, Petr Spacek wrote: Hello, is there any user of CSV support built-in to IPA administration tools ("ipa" command)? Do you consider it sane or even useful? Please reply. I've always disliked our use of CSV values on both the command line and internally. They're just weird, nothing else in Unix works like this and as you point out below there are easier better alternatives. Plus with the use of CSV's there is a lot of awkward quoting in a variety of places. On the command line I always thought multiple values should be specified multiple times and internally they should be encapsulated in lists rather than parsing a CSV string (if it's logically a list then why isn't it a list?) However at this juncture I'm not sure we can make such a change, we have a published API that we would be violating. But perhaps we're not so far down the road we can't make such a change and we're better off doing it now while there is even a chance. It's not clear to me how much the command line is being used and specifically with CSV values. Do I think CSV's are sane and useful? No. Can we change that? That's a whole other story. I wanted to add single TXT record with double quotation marks (") inside the TXT data. I spent some time figuring out how it is supposed to work ... and with help of Petr^3 I managed to write the command. The resulting command (for BASH) is absolutely crazy: ipa dnsrecord-add example.test. newrec --txt-rec='"""created on 13:01:23"""' Do we really need support for this piece of insanity? Shells can do the same thing with much less pain :-) IPA with CSV support can add multiple attributes at once, e.g. ipa dnsrecord-add example.test. newrec --txt-rec=1,2,3,4,5,6,7,8,9 will add TXT records with value 1, 2, 3 etc. BASH can do the same thing (without the escaping hell): ipa dnsrecord-add example.test. newrec --txt-rec={1,2,3,4,5,6,7,8,9} and ipa dnsrecord-add example.test. newrec --txt-rec={1..9} BASH would expand to ipa dnsrecord-add example.test. newrec --txt-rec=1 --txt-rec=2 --txt-rec=3 --txt-rec=4 --txt-rec=5 --txt-rec=6 --txt-rec=7 --txt-rec=8 --txt-rec=9 Do we already have CSV support? Where is it used? It is not clear to me if BASH example above requires the CSV support or it does expansion on its own. Please explain. We already have CSV support. It's a mechanism that allows multiple values to be passed for one command line argument. The alternate approach is rather than having one command line arg that takes multiple values is to allow multiple command line args, each one taking a single value. This is the UNIX methodology. I believe the original thinking was who would want to type out multiple command line args, it's too verbose. However the shell expansion illustrated above shows how with simple shell syntax one can have succicent args and allow the shell to expand them into the preferred verbose form. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] CSV support in IPA administration tools - to be, or not to be?
On 01/11/2013 03:52 PM, Dmitri Pal wrote: On 01/11/2013 03:27 PM, John Dennis wrote: On 01/11/2013 03:10 PM, Dmitri Pal wrote: On 01/10/2013 11:00 AM, John Dennis wrote: On 01/10/2013 08:15 AM, Petr Spacek wrote: Hello, is there any user of CSV support built-in to IPA administration tools ("ipa" command)? Do you consider it sane or even useful? Please reply. I've always disliked our use of CSV values on both the command line and internally. They're just weird, nothing else in Unix works like this and as you point out below there are easier better alternatives. Plus with the use of CSV's there is a lot of awkward quoting in a variety of places. On the command line I always thought multiple values should be specified multiple times and internally they should be encapsulated in lists rather than parsing a CSV string (if it's logically a list then why isn't it a list?) However at this juncture I'm not sure we can make such a change, we have a published API that we would be violating. But perhaps we're not so far down the road we can't make such a change and we're better off doing it now while there is even a chance. It's not clear to me how much the command line is being used and specifically with CSV values. Do I think CSV's are sane and useful? No. Can we change that? That's a whole other story. I wanted to add single TXT record with double quotation marks (") inside the TXT data. I spent some time figuring out how it is supposed to work ... and with help of Petr^3 I managed to write the command. The resulting command (for BASH) is absolutely crazy: ipa dnsrecord-add example.test. newrec --txt-rec='"""created on 13:01:23"""' Do we really need support for this piece of insanity? Shells can do the same thing with much less pain :-) IPA with CSV support can add multiple attributes at once, e.g. ipa dnsrecord-add example.test. newrec --txt-rec=1,2,3,4,5,6,7,8,9 will add TXT records with value 1, 2, 3 etc. BASH can do the same thing (without the escaping hell): ipa dnsrecord-add example.test. newrec --txt-rec={1,2,3,4,5,6,7,8,9} and ipa dnsrecord-add example.test. newrec --txt-rec={1..9} BASH would expand to ipa dnsrecord-add example.test. newrec --txt-rec=1 --txt-rec=2 --txt-rec=3 --txt-rec=4 --txt-rec=5 --txt-rec=6 --txt-rec=7 --txt-rec=8 --txt-rec=9 Do we already have CSV support? Where is it used? It is not clear to me if BASH example above requires the CSV support or it does expansion on its own. Please explain. We already have CSV support. It's a mechanism that allows multiple values to be passed for one command line argument. The alternate approach is rather than having one command line arg that takes multiple values is to allow multiple command line args, each one taking a single value. This is the UNIX methodology. I believe the original thinking was who would want to type out multiple command line args, it's too verbose. However the shell expansion illustrated above shows how with simple shell syntax one can have succicent args and allow the shell to expand them into the preferred verbose form. So both are already supported and we want to stop using CSV and deprecate it over time? This makes sense if there are good examples of how to use bash expansion. I suggest we create a page and describe preferred method of dealing with the lists and document it. Also do the same with the manual, i.e. review it to make sure we do not show CSV syntax in the docs, same with the man pages. On the project page we will say that CSV will not be added to the new and existing commands and will be deprecated over time (probably by IPA version 4). Do I get it right? I'm not sure both are currently supported. I'm not sure we permit multiple args with the same name and aggregate them, I thought that was part of the proposal. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] how do i apply patch?
On 01/12/2013 06:52 AM, Umarzuki Mochlis wrote: 2013/1/12 John Dennis : 1) Download the source rpm matching the version you have installed, add the patch, rebuild the rpm locally, install the locally built rpm. how do i 'add the patch' to source rpm? any documentation that i can follow to do this? There is a ton of documentation on the web on how to work with RPM. I could write out the steps but it would be inferior to the extensive doc you can look-up on Google. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] freeipa radius cisco
On 01/16/2013 11:44 AM, Han Boetes wrote: This might be somewhat off-topic but I'll ask anyway. First my questions: How do I get the cisco device -- a 3750 with the latest software image -- to use EAP-TTLS and what am I missing for the rest. Sorry, I can't help you with cisco configuration, maybe others can. But I can help with FreeRADIUS. # Executing group from file /etc/raddb//sites-enabled/default +- entering group Kerberos {...} rlm_krb5: [hb] krb5_sname_to_principal failed: Hostname cannot be It's failing because it's finding a bogus value for the service principal. This is configured in /etc/raddb/modules/krb5, by default it's krb5 { keytab = /path/to/keytab service_principal = name_of_principle } How did you configure these? -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] freeipa radius cisco
On 01/18/2013 09:31 AM, Han Boetes wrote: In the users file DEFAULT Auth-Type = Kerberos Service-Type = NAS-Prompt-User, cisco-avpair = "shell:priv-lvl=15" Be careful! It's almost never a good idea to set the Auth-Type in the user config. Why? Because normally the server figures out the best Auth-Type to use for a given Auth-Request based on the contents of the Auth-Request packet. The contents of the Auth-Request packet depends exclusively on the configuration of the user's device, something you typically do not have control over (think of random user trying to connect with unknown device). The FR server figures out which Auth-Type to use based on it's configuration and set of policy rules, all of which you can write. The problem comes when a user sends an Auth-Request whose contents does not math the Auth-Type you've forced on them, then things will completely *fail*. Using DEFAULT for the Auth-Type is even a more pernicious problem because you're saying apply this to everyone that lands in the default category. There are a few Auth-Type's the server can't figure out on it's own, kerberos is one of them (because fundamentally it's no different than pap in terms of what the client sends). There are a number of approaches one can take to address this issue via policy configuration in the server, but I'm sorry to say I don't have time to document and test all those at the moment. All I'm trying to say is what you've done above will work only in a very constrained scenario, it is not a general solution. The FreeRADIUS list is filled with folks attempts to force an Auth-Type in the users file only to discover their woes. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] freeipa radius cisco
On 01/18/2013 10:13 AM, John Dennis wrote: On 01/18/2013 09:31 AM, Han Boetes wrote: In the users file DEFAULT Auth-Type = Kerberos Service-Type = NAS-Prompt-User, cisco-avpair = "shell:priv-lvl=15" Be careful! It's almost never a good idea to set the Auth-Type in the user config. Why? Because normally the server figures out the best Auth-Type to use for a given Auth-Request based on the contents of the Auth-Request packet. The contents of the Auth-Request packet depends exclusively on the configuration of the user's device, something you typically do not have control over (think of random user trying to connect with unknown device). The FR server figures out which Auth-Type to use based on it's configuration and set of policy rules, all of which you can write. The problem comes when a user sends an Auth-Request whose contents does not math the Auth-Type you've forced on them, then things will completely *fail*. Using DEFAULT for the Auth-Type is even a more pernicious problem because you're saying apply this to everyone that lands in the default category. There are a few Auth-Type's the server can't figure out on it's own, kerberos is one of them (because fundamentally it's no different than pap in terms of what the client sends). There are a number of approaches one can take to address this issue via policy configuration in the server, but I'm sorry to say I don't have time to document and test all those at the moment. All I'm trying to say is what you've done above will work only in a very constrained scenario, it is not a general solution. The FreeRADIUS list is filled with folks attempts to force an Auth-Type in the users file only to discover their woes. Here are a couple of threads I found on the freeradius-users list which might be of help to you: You should use a TLS tunnel with Kerberos auth because the user's password is sent in the request packet, this explains some of the issues with doing krb inside the inner tunnel of the server: http://lists.freeradius.org/pipermail/freeradius-users/2011-February/051625.html This is a how-to someone wrote up on using kerberos with FreeRADIUS, sorry I haven't read it to check for accuracy, but it might be helpful. http://lists.freeradius.org/pipermail/freeradius-users/2012-December/064375.html -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] IPA Create User
On 02/01/2013 10:26 PM, It Meme wrote: Hi Dimitri: Thank you for your helpful posts. Do you know of any organization that provisions accounts and groups in real-time, from an external IdM system, to IPA, via CLI? We have an IdM system which will be reading data from HR, and making 'joiner, mover, leaver, decisions' - accounts are provisioned, deleted, groups changed etc based on the HR data. Is it feasible to consider the IdM system calling the CLI, via scripts, to create/delete accounts, manage groups, in near real-time? Calling a script does not take much time (especially compared to the elapsed time it takes for the command to complete), it would only be an issue if you were trying to do a number of transactions per second, but it doesn't sound like your HR dept is going to need that kind of throughput. It's also possible to call our API from Python, others have done this. Whether your IdM forks out to a shell script or to a Python script would be negligible compared to the total elapsed time to complete the operation. I suppose the answer to your question begs another, what's your definition of "real time"? If your IdM triggers a transaction and it completes within a few seconds is that real time? John -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] IPA Create User
On 02/04/2013 07:07 PM, It Meme wrote: Thank you John for your helpful reply. Near real time will be sufficient - within the 5 min range. Will it be practical when managing a user's groups - these can happen when a user moves within the organization or is terminated. I'm not sure we've done timing measurements on various operations, but in general most IPA commands are fast executing in sub-second elapsed time on the server. Latency on the client side can be introduced by such things as authentication (mitigated by the use of client sessions), network latencies between the client and the server, DNS resolution, etc. Those types of network induced latencies can be very hard to predict because it depends on a number of external factors having nothing to do with IPA per se. Elapsed time on the server is also influenced by LDAP tuning (e.g. indexes), memory, available CPU, etc. Things like adding a user, or adding a user to a group are not compute intensive and should execute quickly. For your intended use I don't see any issues with the elapsed time for command execution. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Upgrade to 3.1.2: web UI no longer works
On 02/05/2013 09:52 AM, Thomas Sailer wrote: Hi, I've just upgraded from F16 to F18 and thus freeipa v3.1.2. It basically works, on the command line. ipa user-show xxx works. The Web UI however no longer works. I get the login window with "Your session has expired. Please re-login.", no matter whether I use kerberos or password login. The httpd logs don't seem to be very informative. /var/cache/ipa/sessions/ is empty. Could someone point me to where I could find more information to debug this problem? In /etc/ipa/default.conf on the server add this line: debug=True Then restart the server (actually you only need to restart httpd, e.g. systemctl restart httpd.service) Then you should see a lot of debug messages in /var/log/httpd/error_log /var/cache/ipa/sessions is historical cruft, you won't find anything there. Once you get the debug trace one of us can help diagnose it. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Upgrade to 3.1.2: web UI no longer works
On 02/05/2013 12:11 PM, Thomas Sailer wrote: Thanks, John! See the log below. The only thing that looks strange to me is expiration_timestamp=1970-01-01T01:00:00. Where does this time come from? That's the initial value of zero on the expiration timestamp, the beginning of the UNIX epoch, it's reset later, nothing to worry about here. Could you please check if ipa-memcached is running? The easiest way is with % ipactl status Also when you send log snippets could you either send them as a text attachment or via a pastebin, your mailer is wrapping the lines which makes it hard to read. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Upgrade to 3.1.2: web UI no longer works
On 02/05/2013 01:40 PM, Thomas Sailer wrote: On 02/05/2013 06:32 PM, John Dennis wrote: % ipactl status # ipactl status Directory Service: RUNNING krb5kdc Service: RUNNING kadmin Service: RUNNING named Service: RUNNING httpd Service: RUNNING pki-cad Service: RUNNING ipa: INFO: The ipactl command was successful Apparently, it isn't... I've started it using: # systemctl restart ipa_memcached.service # systemctl enable ipa_memcached.service But still, it's not listed with ipactl status (systemctl says it started successfully) Now I'm getting "IPA Error 903". Thanks, Tom The fact ipactl does not know about ipa-memcache indicates something went wrong with your upgrade, most likely related to ldap. We probably want to look in /var/log/ipaupgrade.log to see if there were problems. After manually starting ipa-memcached your log shows sessions are working correctly, that's good. That also means the ipa code was installed correctly, once again this points to an LDAP upgrade error, not an RPM install error. (FWIW ipactl reads LDAP to learn what services it has to run). Also, thank you very much for attaching the log, it's *much* easier to read :-) -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] creating group via CLI
On 02/07/2013 08:42 PM, Umarzuki Mochlis wrote: Hi, Is it possible to create groups and add users to that group via CLI? So far, I could not find any sample command on doing that. The ipa CLI has help % ipa help user % ipa help group % ipa help user-add etc. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Python Client
On 02/08/2013 05:29 PM, It Meme wrote: Hi: Scenario: 1) User is created via LDAP call to IPA (i.e.the 389 Directory Server) The above user will not have IPA-specific attributes. Can we use the Python Library, or CLI, to modify the account to IPA-ize it? You're really better off using the IPA API directly rather than trying to bypass it. Why? Because we implement additional logic inside the commands. If you could achieve everything IPA does by just modifying an LDAP server there wouldn't be a need for IPA. A good example of this is group membership, some of that logic is handled directly by a plugin to the 389 DS, but a large part of it is implemented in the IPA commands that manage users and groups. You really don't want to bypass it. You have a number of options on how to call the IPA commands: 1) the ipa command line client 2) sending the command formatted in JSON to the server 3) sending the command formatted in XML-RPC to the server 4) calling the command from your own python code 5) using the web GUI It's really not hard to call the IPA command line client from a program, typically this is done via a "system" command of which there are a number of variants. The following thread has a discussion of how to invoke one of our commands from Python code, this particular email response from Martin shows how it can be done in in about half a dozen lines of code. https://www.redhat.com/archives/freeipa-users/2012-June/msg00334.html What I'm not understanding why you're avoiding using the commands we provide. If you're not familiar with how to call another program/process we can help you or just google it. Or is the problem your existing management system does not provide you with any "hooks" to execute code when an action occurs. But from everything you've said so far you imply it does provide such hooks. Perhaps if you could be more specific we could be more helpful. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Account Expiration
On 02/12/2013 01:40 PM, Rob Crittenden wrote: Is it possible to ipa to send a email to user when his account is about to expire (the current date is near krbprincipalexpiration date) ? Not currently. In 3.0+ we will provide a notice when one logs into the WebUI but that's it. We can't be sure that an MTA is properly configured on the IPA server at install time so we have punted on this for a while. We don't want to get into the business of picking and configuring one. This is one of those things that seems really easy but gets complicated the deeper you dig into it. We're open to suggestions/patches. Yeah, I don't think we want to be in the business of installing and configuring an MTA. However, we should be able to detect if one is available and use it if it is. I think it would be reasonable to restrict it to LMTP with a Unix domain socket (most MTA's support this). Then our config would have a LMTP domain socket pathname, if that pathname exists and we can connect to it we use, if not we fallback to not generating any mail. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Non-human users
On 02/15/2013 12:32 PM, Orion Poplawski wrote: On 02/15/2013 09:45 AM, Petr Viktorin wrote: On 02/15/2013 05:36 PM, Orion Poplawski wrote: Is there a recommended way to distinguish between "real" human user accounts in IPA and non-human "system" accounts in IPA? What kind of system accounts do you have in IPA? Consider not storing them in IPA at all. Yeah, that seems like the better idea, but: I think the main issue we've run into is needing the apache user to be a member of groups in ldap, and that not working unless the apache user was in ldap as well. Another example is a backup user account that backup software logs in as. Also some accounts that own files and some services run as that are needed on multiple machines. I suppose we could use puppet to manage those, but ldap seems more convenient. Generally system users do not need accounts. Most daemons define a system user only for the purposes of having a uid they can drop privileges to after starting as root. These users typically do not have shells (technically their shell is /sbin/nologin) nor home directories. Also these system accounts typically have fixed well known uid's. Also these system users are automatically created when you install the package. Thus there is little point in trying to manage them. If you find yourself with a need to manage them step back and ask yourself why. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Non-human users
The example cited was the apache user, a system daemon. For system users bound to system daemons I stand by what I said. If you want to talk about other system users not bound to a daemon than state that rather than confusing the issue. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Non-human users
On 02/15/2013 01:35 PM, Rob Crittenden wrote: John Dennis wrote: The example cited was the apache user, a system daemon. For system users bound to system daemons I stand by what I said. If you want to talk about other system users not bound to a daemon than state that rather than confusing the issue. He cited a backup user. That isn't tied to a daemon. The original message said this: I think the main issue we've run into is needing the apache user ... -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Non-human users
On 02/15/2013 01:39 PM, Orion Poplawski wrote: On 02/15/2013 11:38 AM, John Dennis wrote: On 02/15/2013 01:35 PM, Rob Crittenden wrote: John Dennis wrote: The example cited was the apache user, a system daemon. For system users bound to system daemons I stand by what I said. If you want to talk about other system users not bound to a daemon than state that rather than confusing the issue. He cited a backup user. That isn't tied to a daemon. The original message said this: I think the main issue we've run into is needing the apache user ... And: Another example is a backup user account that backup software logs in as. Also some accounts that own files and some services run as that are needed on multiple machines. I suppose we could use puppet to manage those, but ldap seems more convenient. O.K. but I want to make sure you understand the difference. If you give login or other permissions to a network facing system daemon you're opening a huge security hole. Adding the apache user to the set of users managed by IPA is quite dangerous unless you are extraordinarily careful to remove privileges normally granted by IPA, it could lead to the complete compromise of your network. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Non-human users
On 02/15/2013 02:23 PM, Orion Poplawski wrote: On 02/15/2013 12:01 PM, Orion Poplawski wrote: I've been trying to track down any bugs I may have filed without success, but I'm pretty sure I tried at first adding a system user to LDAP groups and that not working unless the system user was in LDAP. This may have been before I started using SSSD on the servers so I'll need to retest this. This still appears to be the case. As soon as I removed the system user from our current ldap database, id now longer reported any other group memberships. This is with the default using "memberUid" for group membership. With the IPA schema of recording group membership with the full dn, it seems the user would have to be in the database to have a dn. Yes you're right, the user has to exist in LDAP in order to be a member of a group managed in LDAP. If your goal is not to have system users returned in a ldap search you'll have to filter them (e.g. adding (uid >= 1024) to the search filter because system users are usually less than some magic number, it used to be 512, now it's 1024 I believe). Adding that (or some other filter criteria) to every LDAP client in your enterprise is probably not viable. I don't think setting ACL's to prevent specific users from being returned in searches is viable either because they need to visible during the operations they're involved in. The problem as I see it is that IPA by design stores users in a "flat" namespace. That means you cannot partition users by putting them in different LDAP containers (trees). During the design of IPA the issue of whether we would use a flat namespace or permit different namespaces (via LDAP containers, conventionally called organizational units, i.e. OU's) came up. There was a sentiment that OU's had historically been problematic, hence we have a flat namespace and partitioning would be done via filtering. Thus only thing I can suggest at the moment is filtering, perhaps others have a better idea. Your other alternative is not put these system users in LDAP and instead use local users & groups managed via some other mechanism (puppet?). I'm not sure this issue has come up before, it does present some interesting issues. John -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Non-human users
On 02/15/2013 03:46 PM, Simo Sorce wrote: This is an interesting use case, it would probably be appropriate to have a RFE filed to allow to create ipa users marked as 'non-person' so that they are not assigned the person objectclass. Yes, that addresses one large component of the problem. But the part of the requirement is not to have non-humans show up in every client (e.g. mail clients) that support LDAP directory lookups. That means they have to modify the filter on every client. That's a tall order :-( -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Non-human users
On 02/15/2013 03:57 PM, Orion Poplawski wrote: On 02/15/2013 01:56 PM, John Dennis wrote: On 02/15/2013 03:46 PM, Simo Sorce wrote: This is an interesting use case, it would probably be appropriate to have a RFE filed to allow to create ipa users marked as 'non-person' so that they are not assigned the person objectclass. Yes, that addresses one large component of the problem. But the part of the requirement is not to have non-humans show up in every client (e.g. mail clients) that support LDAP directory lookups. That means they have to modify the filter on every client. That's a tall order :-( Actually, this would cover it. The LDAP address book searches look for attributes that the *person objectclasses provide. Without them, they are excluded. Interesting, before I replied I checked the filter in my Thunderbird client and it's set to (objectclass=*). I don't know if I modified it as some point or if it's the default, I assumed it's the default. I suspect it's the default filter for many clients. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Non-human users
On 02/15/2013 04:16 PM, Orion Poplawski wrote: On 02/15/2013 02:02 PM, John Dennis wrote: On 02/15/2013 03:57 PM, Orion Poplawski wrote: On 02/15/2013 01:56 PM, John Dennis wrote: On 02/15/2013 03:46 PM, Simo Sorce wrote: This is an interesting use case, it would probably be appropriate to have a RFE filed to allow to create ipa users marked as 'non-person' so that they are not assigned the person objectclass. Yes, that addresses one large component of the problem. But the part of the requirement is not to have non-humans show up in every client (e.g. mail clients) that support LDAP directory lookups. That means they have to modify the filter on every client. That's a tall order :-( Actually, this would cover it. The LDAP address book searches look for attributes that the *person objectclasses provide. Without them, they are excluded. Interesting, before I replied I checked the filter in my Thunderbird client and it's set to (objectclass=*). I don't know if I modified it as some point or if it's the default, I assumed it's the default. I suspect it's the default filter for many clients. Hmm, that is the filter in TB for me too, but: [15/Feb/2013:11:17:21 -0700] conn=931 op=1 SRCH base="ou=people,dc=nwra,dc=com" scope=2 filter="(|(mail=*apache*)(cn=*apache*)(givenName=*apache*)(sn=*apache*))" attrs="description notes title sn sn mozillaHomeLocalityName givenName mozillaHomeState mail mozillaWorkUrl workurl labeledURI o company mozillaNickname mozillaNickname mobile cellphone carphone modifyTimestamp nsAIMid nsAIMid telephoneNumber birthyear c c mozillaHomeStreet cn cn postalCode zip mozillaCustom1 custom1 mozillaHomeCountryName homePhone st region mozillaCustom2 custom2 mozillaSecondEmail mozillaSecondEmail facsimileTelephoneNumber facsimileTelephoneNumber mozillaCustom3 custom3 mozillaUseHtmlMail mozillaUseHtmlMail mozillaHomeStreet2 birthday street street postOfficeBox mozillaCustom4 custom4 mozillaHomeUrl homeurl l l pager pagerphone ou department departmentNumber orgunit birthmonth mozillaWorkStreet2 mozillaHomePostalCode objectClass" is what I see in the LDAP server log I don't know, beats me as to why there is no objectclass filter component. Perhaps TB is smart enough to know (objectclass=*) is effectively a no-op and ignores it when it builds the final filter. What happens if you set the TB filter to (objectclass=person)? -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Non-human users
On 02/15/2013 04:54 PM, Orion Poplawski wrote: On 02/15/2013 02:34 PM, John Dennis wrote: On 02/15/2013 04:16 PM, Orion Poplawski wrote: Hmm, that is the filter in TB for me too, but: [15/Feb/2013:11:17:21 -0700] conn=931 op=1 SRCH base="ou=people,dc=nwra,dc=com" scope=2 filter="(|(mail=*apache*)(cn=*apache*)(givenName=*apache*)(sn=*apache*))" attrs="description notes title sn sn mozillaHomeLocalityName givenName mozillaHomeState mail mozillaWorkUrl workurl labeledURI o company mozillaNickname mozillaNickname mobile cellphone carphone modifyTimestamp nsAIMid nsAIMid telephoneNumber birthyear c c mozillaHomeStreet cn cn postalCode zip mozillaCustom1 custom1 mozillaHomeCountryName homePhone st region mozillaCustom2 custom2 mozillaSecondEmail mozillaSecondEmail facsimileTelephoneNumber facsimileTelephoneNumber mozillaCustom3 custom3 mozillaUseHtmlMail mozillaUseHtmlMail mozillaHomeStreet2 birthday street street postOfficeBox mozillaCustom4 custom4 mozillaHomeUrl homeurl l l pager pagerphone ou department departmentNumber orgunit birthmonth mozillaWorkStreet2 mozillaHomePostalCode objectClass" is what I see in the LDAP server log I don't know, beats me as to why there is no objectclass filter component. Perhaps TB is smart enough to know (objectclass=*) is effectively a no-op and ignores it when it builds the final filter. What happens if you set the TB filter to (objectclass=person)? Yup, then it adds it: filter="(&(objectClass=person)(|(mail=*apac*)(cn=*apac*)(givenName=*apac*)(sn=*apac*)))" O.K. I presume it's obvious the consequence of this little experiment is that if we do an an RFE that results in removing the person objectclass from non-human users you'll have to configure a custom LDAP search filter in every client in your enterprise if you don't want them to see non-human users in their search results. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Cannot obtain CA Certificate
On 02/18/2013 09:06 PM, John Moyer wrote: Peter, The client is pointing to DNS for the server. Here is the log info from the ipa-client-log (in /var/log/). I haven't tried the other stuff yet, I'll respond back when I get a chance to check out the CA cert things. 2013-02-19T02:01:37Z DEBUG args=kinit ipa-b...@example.com When the client installer tries to retrieve the CA cert from LDAP it uses a GSSAPI bind and they error you're getting is that it cannot perform a bind with the credentials from above. Did you provide the password for ipa-bind? Are you running the client install interactively? Is the realm EXAMPLE.COM really correct? Are you able to do a kinit for ipa-b...@example.com on the client successfully? Are your kerberos ports open? -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Trouble creating replica
On 02/19/2013 06:58 AM, Bret Wortman wrote: I have a server running freeipa and I want to migrate it to a new host. I had thought that the easiest way might be to create a replica and load that onto the new host, but this is proving problematic: # ipa-replica-prepare ipamaster.my.com <http://ipamaster.my.com> --ip-address 10.0.0.46 Directory Manager (existing master) password: Preparing replica for ipamaster.my.com <http://ipamaster.my.com> from oldmaster.my.com <http://oldmaster.my.com> Creating SSL certificate for the Directory Server preparation of replica failed: cannot connect to 'https://oldmaster.my.com:9444/ca/ee/ca/profileSubmitSSLClient': [Errno -5985] Cannot resolve oldmaster.my.com <http://oldmaster.my.com> using family PR_AF_INET6 And then a stack trace follows. # netstat -rn | grep 9444 # lsof -i:9444 # _ _ I've also tried connecting to that URL via Firefox without success. It's just not listening there. What do I need to check? Someone else is running some apps (redmine and others) using Passenger on that server as well; could it be obscuring the port somehow? We're not running IPV6, so I'm not sure why it's being referenced I can't comment on why you can't connect but I can explain the error message. It's an internal mistake, if we can't connect we try another address family, that logic is incorrect and I thought we had fixed in this ticket https://fedorahosted.org/freeipa/ticket/2695, but apparently we didn't. Anyway the error message is a red herring, your connection problems lie elsewhere. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Trouble creating replica
On 02/20/2013 08:43 AM, Bret Wortman wrote: > [root@oldmaster]# pkicontrol start ca PKI-IPA PKI-IPA is an invalid 'pki-ca' instance [root@oldmaster]# Is there another, preferred way to start it? pkiconsole is used to monitor/configure your instance, it's a GUI application. Perhaps it can also be used to start/stop instances but I've never seen it used that way and we don't use pkiconsole at all. Normally the pki-ca instance is controlled using the same service commands for any other daemon. Some of this has been in flux so the details may depend on your exact OS. If you don't provide a specific instance to start/stop then the service command will apply the action to all your instances, usaully this is fine as usaully you only have one instance. As for debugging what is going on. pki-ca is a tomcat instance. You need to locate it's log files under /var/log depending on the release it can be named slightly differently but it should be obvious. You need to understand how a tomcat instance starts, again this depends on the release. Early start up messages will be written to catalina.out, those are tomcat specific messages, if you have problems opening sockets (for instance bad certs) it should show up in this file. Once tomcat hands control over to the application (i.e. pki-ca) you will see messages in the "debug" file located under the /var/log/pki-ca (or whatever, depends on the release) directory. As I said it should be easy to find. Look in that file for obvious problems. HTH, I forget the exact version you're running on which OS. If the above is not specific enough we can get the dogtag folks to jump in. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] --external-ca is a bit confusing.
On 02/21/2013 07:23 PM, Kendrick . wrote: It is part of my initial setup. I copied the ipa.csr in to cacert's signing system so that the certificates would be valid outside of my local domain. and it errors because the host information said certificate authority instead of the host name if I understand that error mesage properly. I am trying to get the csr to provide all the information needed by cacerts free signing service. I was expecting to be able to use the user certificates that freeipa makes to sign emails and such that would go externally. The CA will only sign a cert for a domain registered to you. To see what domain the CSR is for dump it's contents using openssl, for example: openssl req -in ipa.csr -noout -text Does the CN in the subject match the domain you registered with cacert.org? If not it's not going to sign it. But wait, there's more, you're not just asking cacert to sign a plain cert you're asking it to sign a CA cert effectively creating a sub-CA of cacert. That means with that cert you can issue new certs and cacert will "vouch" for them, but of course they can't control who you're issuing certs to which is a significant security issue. This FAQ entry from cacert will help clarify: http://wiki.cacert.org/SubRoot -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] What does the "u" mean in IPA messages?
On 02/28/2013 04:18 PM, KodaK wrote: When performing an operation with the IPA tools, I get a message every time similar to this: ipa: INFO: Forwarding 'hbactest' to server u'https://ipaserver/ipa/xml' What does it mean? I've never seen it say anything other than "u" (that I've noticed.) A pointer to documentation is preferred, but I've been looking and haven't found anything. (Lots of stuff on the International Phonetic Alphabet's use of "u" though. I think I'm qualified to edit dictionaries now.) It means unicode, It's a Python'ism. In Python2 there are two different string types str and unicode. str's are have 8-bit characters, unicode have wide characters (either 16-bit UCS2 or 32-bit UCS4) depending on how Python was built (unicode is UCS4 on our builds). Since IPA in internationalized we use unicode for all strings. What the u prefix is telling you is the type of the string. The only reason you see it is because in some places we use the repr method to output string data and the repr method prefixes unicode with a u character. We've been fixing places where repr method is used, not sure if this is one of those or not. We were using repr because early on we were not consistent with whether we used str's or unicode objects and it was handy to know the difference, it's not so much of an issue any more. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] What does the "u" mean in IPA messages?
On 02/28/2013 05:34 PM, KodaK wrote: On Thu, Feb 28, 2013 at 3:27 PM, John Dennis wrote: On 02/28/2013 04:18 PM, KodaK wrote: When performing an operation with the IPA tools, I get a message every time similar to this: ipa: INFO: Forwarding 'hbactest' to server u'https://ipaserver/ipa/xml' What does it mean? I've never seen it say anything other than "u" (that I've noticed.) A pointer to documentation is preferred, but I've been looking and haven't found anything. (Lots of stuff on the International Phonetic Alphabet's use of "u" though. I think I'm qualified to edit dictionaries now.) It means unicode, It's a Python'ism. In Python2 there are two different string types str and unicode. str's are have 8-bit characters, unicode have wide characters (either 16-bit UCS2 or 32-bit UCS4) depending on how Python was built (unicode is UCS4 on our builds). Since IPA in internationalized we use unicode for all strings. What the u prefix is telling you is the type of the string. The only reason you see it is because in some places we use the repr method to output string data and the repr method prefixes unicode with a u character. We've been fixing places where repr method is used, not sure if this is one of those or not. We were using repr because early on we were not consistent with whether we used str's or unicode objects and it was handy to know the difference, it's not so much of an issue any more. Ah, thanks for the explanation. If I build parsing scripts for things, is the "u" going to disappear in the future with the discontinuation of the repr method? (That's what set this off in the first place.) You should not depend on the type prefix. There are other prefixes besides u but I think u is the only one you'll see in practice. My suggestion for parsing would be to permit the prefix but to ignore it if it's present. BTW, why are you parsing diagnostic output? They are not part of the official API. We do not have any consistency rules for INFO and DEBUG messages, they can change at any time and often do. On the other hand command output is fairly consistent and not subject to the capricious whims of developers. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] What does the "u" mean in IPA messages?
On 03/01/2013 03:17 PM, KodaK wrote: On Thu, Feb 28, 2013 at 5:01 PM, John Dennis wrote: On 02/28/2013 05:34 PM, KodaK wrote: BTW, why are you parsing diagnostic output? I haven't actually started yet, I was just getting my bearings. I was going to wrap the commands in some scripts so I can do things like allow an auditor to view the results of an HBAC test without being able to modify them. Among other things. Is there a way to turn off the diagnostic messages? They appear to be on by default. INFO messages are output when the verbose flag is enabled DEBUG messages are output when the debug flag is enabled Those flags can either be set in a config file (/etc/ipa/default.conf or ~/.ipa/default.con) or via a command line argument. If you haven't passed the verbose flag to the command then it must be set in one of the config files. Petr Viktorin recently cleaned up how messages are managed in the command line tools (I don't think this has made it out into a public release yet). So there may be changes coming you'll want to be aware of, perhaps Petr might fill us in on what's different. I think we had some client tools that forced verbose to be enabled when it should have respected a command line option and/or config option. I think that's some of what Petr fixed. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] What does the "u" mean in IPA messages?
On 03/01/2013 04:01 PM, John Dennis wrote: On 03/01/2013 03:17 PM, KodaK wrote: On Thu, Feb 28, 2013 at 5:01 PM, John Dennis wrote: On 02/28/2013 05:34 PM, KodaK wrote: BTW, why are you parsing diagnostic output? I haven't actually started yet, I was just getting my bearings. I was going to wrap the commands in some scripts so I can do things like allow an auditor to view the results of an HBAC test without being able to modify them. Among other things. Is there a way to turn off the diagnostic messages? They appear to be on by default. INFO messages are output when the verbose flag is enabled DEBUG messages are output when the debug flag is enabled Those flags can either be set in a config file (/etc/ipa/default.conf or ~/.ipa/default.con) or via a command line argument. If you haven't passed the verbose flag to the command then it must be set in one of the config files. Petr Viktorin recently cleaned up how messages are managed in the command line tools (I don't think this has made it out into a public release yet). So there may be changes coming you'll want to be aware of, perhaps Petr might fill us in on what's different. I think we had some client tools that forced verbose to be enabled when it should have respected a command line option and/or config option. I think that's some of what Petr fixed. Here is the design document for the work Petr did, HTH http://freeipa.org/page/V3/Logging_and_output -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] ipa-* tools throws errors
On 03/11/2013 02:05 PM, David Fitzgerald wrote: Here is the output of the dig command. Cyclone does show up here , but our networking people say there are no srv records in our current db. I still think the trouble I am having has to do with the Internal Server Error I get when I run ipa commands. ; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.17.rc1.el6.3 <<>> -t srv _ldap._tcp.esci.millersville.edu ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27213 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2 ;; QUESTION SECTION: ;_ldap._tcp.esci.millersville.edu. IN SRV ;; ANSWER SECTION: _ldap._tcp.esci.millersville.edu. 600 IN SRV0 100 389 cyclone.esci.millersville.edu. ;; AUTHORITY SECTION: _tcp.esci.millersville.edu. 3600 IN NS corsair.millersville.edu. _tcp.esci.millersville.edu. 3600 IN NS garfield.millersville.edu. ;; ADDITIONAL SECTION: corsair.millersville.edu. 3600 IN A 192.206.29.2 garfield.millersville.edu. 3600 IN A 166.66.86.144 ;; Query time: 1 msec ;; SERVER: 166.66.86.144#53(166.66.86.144) ;; WHEN: Mon Mar 11 13:55:36 2013 ;; MSG SIZE rcvd: 176 -Original Message- From: freeipa-users-boun...@redhat.com [mailto:freeipa-users-boun...@redhat.com] On Behalf Of David Fitzgerald Sent: Friday, March 08, 2013 12:04 PM To: Martin Kosek Cc: freeipa-users@redhat.com Subject: Re: [Freeipa-users] ipa-* tools throws errors Thanks for getting back to me! I don't think the problem has anything to do with DNS. I (finally) ran an ipa command with the verbose flags -vv and found that it IS trying to contact aurora.esci.millersville.edu, it fails then tries to contact cyclone.esci.millersville.edu (still don't know where that comes from). I am getting an 'Internal Server Error' in the output when connecting to aurora. Here is the output: % ipa -vv passwd ipa: INFO: trying https://aurora.esci.millersville.edu/ipa/xml send: u'POST /ipa/xml HTTP/1.0\r\nHost: aurora.esci.millersville.edu\r\nAccept-Language: en-us\r\nReferer: https://aurora.esci.millersville.edu/ipa/xml\r\nAuthorization: negotiate ... send: "\n\nping\n\n\n\n" reply: 'HTTP/1.1 500 Internal Server Error\r\n' header: Date: Fri, 08 Mar 2013 16:52:48 GMT header: Server: Apache/2.2.15 (Scientific Linux) header: WWW-Authenticate: Negotiate YIGZBgkqhkiG9xIBAgICAG+BiTCBhqADAgEFoQMCAQ+iejB4oAMCARKicQRvjoEMIFJxPVNU4jtl/7S+eC6fM0rlJWpV1fJdhoVTKwiR2pa2OHQWRtCjQDfz pBNwNBpt1fMY7M4Bfrqs860toAT6jMfS8Jkqh3Aj9OeuEmpEVHys5pbErjj14OPHxbxTmLdPxFE8eV4ZIDQg40a8 header: Content-Length: 311 header: Connection: close header: Content-Type: text/html; charset=utf-8 ipa: INFO: trying https://cyclone.esci.millersville.edu/ipa/xml ipa: ERROR: Kerberos error: Service u'h...@cyclone.esci.millersville.edu' not found in Kerberos database/ The apache error log gives this: Fri Mar 08 11:52:48 2013] [error] ipa: ERROR: 500 Internal Server Error: xmlserver.__call__: KRB5CCNAME not defined in HTTP request environment. I have no idea what that means. Can you help? It looks like the web server on aurora isn't configured for kerberos auth on the ipa/xml location. If it were it would have created a KRBCCAME before handing the request to IPA. IPA is complaining it can't find the kerberos credentials. Your client then falls back the server it found in your dns srv record. I can't explain that srv record or whether you've got a valid IPA server running there or not. I would check the apache config on aurora. Do you have a: /etc/httpd/conf.d/ipa.conf file? Are there any .rpmew files under /etc/httpd? Have you restarted httpd on aurora? What are the contents of /etc/httpd/conf.d/ipa.conf? -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] LDAP authentication for 3rd party
On 04/11/2013 02:47 PM, Bartek Moczulski wrote: hi, I've got a problem with using IPA as authentication source over LDAP. Generally there are two approaches to LDAP authentication: 1. bind using admin account and read passwords from user objects (but in ipa you cannot read passwords through ldap, right?) 2. "bind to authenticate" - service tries to log in to ldap with user's credentials. If login is successful authentication is also succesful - this approach does not work because you cannot login to IPA ldap using bare username, you need a full LDAP DN. Most applications I know of that do "bind as user" to authenticate also permit you to specify a format string into which the user name is inserted (i.e. the format string is the dn, e.g. "uid=%u,cn=users,cn=accounts,dc=example,dc=com") -or- they do a search to discover the dn. If you application does not support either approach it's broken IMHO. Reading passwords and/or password hashes is not supported for security reasons. Now, I've got a 3rd party application supporting both mentioned above appoaches and the question is - how to make it work with ipa? thanks in advance, Bartek. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] FreeIPA dual stacked
On 04/15/2013 11:45 AM, Adam Bishop wrote: Hi, I've just had a go at deploying FreeIPA v3.1.3 and have hit a minor road bump. The server hostname resolves to more than one address: :::::4 xxx.xxx.xxx.180 Please provide the IP address to be used for this host name: The answer I would like to give here is both - is this a limitation of the installation script that I can fix up later, or is FreeIPA incompatible with dual-stacked hosts at the moment? We're supposed to work fine with IPv6. Dual stack should also be fine. I know we've done a bunch of testing in this area but apparently something fell through the cracks. I suspect this is an installer only issue where it's validation logic is not sufficiently robust. Please open a bug report so we can address this. I think if you pick one of the addresses and let the install proceed everything should just work. Please let us know if it doesn't. I'm not surprised we still have some IPv6 bumps to smooth out, it doesn't get exercised as much as IPv4. FWIW we fully expect IPv6 enabled systems to be dual stack. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] users account functionality
On 05/02/2013 04:42 AM, Juan Armario wrote: Hi, I'm Juan and I'm building a freeipa application and need to know if it possible integrate a module or if is already developed, the typical functionality when we want an authentication service for our users, like remember password, create users, and send an email for confirmation, or send a account delete request. We have installed the basic freeipa and we need to incorporate this functionality. Exist this or have I to implement it? It's a little hard to understand exactly what you're looking to accomplish, for instance what does "remember password" mean? It doesn't sound like what you're looking for requires adding a plugin module, rather you're looking to add a front-end to IPA which is easy to do with scripts. IPA is quite amenable to scripting because we provide a command line interface. You can either call the ipa command from a shell script or you can write your own Python scripts and invoke the IPA API directly. Be careful though, the type of operations you've described all require administrator privileges, it's not something a general user can do. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Installing a Godaddy Cert with ipa-server-certinstall
On 05/29/2013 01:42 AM, John Moyer wrote: Yea I replaced both certs, however, in my troubleshooting I've found more I'll say symptoms or potential problems, which may stem from this or be independent from it. 1. Showing this error message on restarting the service: EXAMPLE-COM...[29/May/2013:05:30:58 +] - SSL alert: CERT_VerifyCertificateNow: verify certificate failed for cert MyIPA of family cn=RSA,cn=encryption,cn=config (Netscape Portable Runtime error -8172 - Peer's certificate issuer has been marked as not trusted by the user.) The error is saying the CA which signed your new cert is either unknown or untrusted. Trusted CA's must be in the NSS database which is being referenced, which in this case I believe is /etc/httpd/alias. By default we don't add other root CA's to this database so you'll have to add it. To see what is in the database do this: sudo certutil -d /etc/httpd/alias -L -h internal FWIW the "-h internal" means to also examine any preloaded CA's that may have been added with modutil. If CA the signed your cert is one of the standard trusted ones you can add the entire set of trusted CA's with modutil % sudo modutil -add ca_certs -libfile libnssckbi.so -dbdir /etc/httpd/alias But that's a big hammer, you might be better off just manually just adding the CA that signed your cert and adding trust for it. Examples can be found here: http://www.mozilla.org/projects/security/pki/nss/tools/certutil.html -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Installing a Godaddy Cert with ipa-server-certinstall
On 05/29/2013 09:55 AM, John Moyer wrote: John, I see the following when I ran that first command. sudo certutil -d /etc/httpd/alias -L -h internal Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI Go Daddy Secure Certification Authority - The Go Daddy Group, Inc. ,, Go Daddy Class 2 Certification Authority - ValiCert, Inc.,, MyIPACTu,Cu,u So being that I have no fear (or am just real dumb, I really feel it's just both) I used that command and got this error after hitting enter to continue: sudo modutil -add ca_certs -libfile libnssckbi.so -dbdir /etc/httpd/alias WARNING: Performing this operation while the browser is running could cause corruption of your security databases. If the browser is currently running, you should exit browser before continuing this operation. Type 'q ' to abort, or to continue: ERROR: Failed to add module "ca_certs". Probable cause : "Unknown PKCS #11 error.". I then did the first command again (to see what I messed up) and it looks identical as shown below: sudo certutil -d /etc/httpd/alias -L -h internal Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI Go Daddy Secure Certification Authority - The Go Daddy Group, Inc. ,, Go Daddy Class 2 Certification Authority - ValiCert, Inc.,, MyIPACTu,Cu,u My suggestion would be to do the following. 1) Determine the issuer of your new cert (i.e. who signed it). Do this by dumping the text representation of the cert. If one of the certs above is the cert in question you can use certutil % certutil -d /etc/httpd/alias -L -n "xxx" where xxx is the cert nickname or via openssl if you have the cert file available (assuming in pem format) % opnessl x509 -inform PEM -text -in xxx where xxx is the cert file look for the issuer field and make note of it. 2) Is the issuer one of the certs in the above listing? If so use certutil to add trust flags to it (see certutil web page pointed out earlier for examples of adding trust). If the issuer is not already in the list then acquire the issuer cert from godaddy and add it to the database with trust flags turned on. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Installing a Godaddy Cert with ipa-server-certinstall
On 06/10/2013 04:32 PM, John Moyer wrote: > Do you mean doing this? If not let me know. I'm afraid much of what has been done so far amounts to flailing about. The information needed to resolve the problem is contained in your cert. I'm pretty sure I asked for this information previously with detained instructions on how to retrieve it. We need to know the full contents of the cert, including it's extensions and the issuer. Then we need to know the contents of your NSS database. That should be enough to answer the question of why your CA cert is not validating as expected. Either dump the text form of your CA cert and send it along or send us the cert in PEM format and we'll open it up. I suggest you do that in a private email to either me or Rob as opposed to the list. I have tools that will help diagnose why NSS might fail to validate a cert. Also, many public CA will not issue, or will restrict signing CA certs because that opens them up to liability (they can't know what your CA will sign and if they sign your CA they are in effect vouching for any cert you issue). This is another reason it's important to see the contents of the cert, to determine what actions that cert is authorized to perform for and who is authorizing those actions, make sense? John ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Installing a Godaddy Cert with ipa-server-certinstall
On 06/10/2013 04:50 PM, John Dennis wrote: > Either dump the text form of your CA cert and send it along or send us > the cert in PEM format and we'll open it up. Actually in hindsight send us the all the Godaddy certs in PEM format only, the tools need to read PEM format. Text format would be interesting for us humans, but the tools need PEM and we can always generate the text format from PEM anyway. John ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] free radiuse
On 09/03/2013 12:51 AM, Jason Prouty wrote: > I have IPA-server installed and working for my linux servers > > I have several cisco Routers 2821 and juniper FW that I would like to > authenticate against IPA. > > I have a free radius .schema file. First you have to tell us what authentication protocols these devices support. Then we can tell you the best approach. FWIW adding radius schema to freeipa LDAP is *not* likely to be a viable option because many of the radius schema elements conflict with how IPA manages things. You're better off using the IPA schema and configuring FreeRADIUS to use it. -- John ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Ldap schema
On 09/04/2013 05:41 PM, Jason Prouty wrote: > I have the radius.schema file how do I add that into my ldap schema on > IPA server. > > I see several ldif files /etc/dirsrv//schema but they are ldif > files > > > > If I can extend my schema integration to free radius should be easy. Is there a reason you ignored the prior response? -- John ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Ldap schema
On 09/05/2013 02:29 AM, Dmitri Pal wrote: > On 09/05/2013 12:38 AM, Jason Prouty wrote: >> This is the AV-Pair I would like to implement to pass back to radius. >> >> >> dn: cn=priv-15,ou=cisco,ou=radius,dc=example,dc=com >> objectClass: radiusObjectProfile >> objectClass: radiusprofile >> cn: priv-15 >> radiusReplyItem: cisco-avpair = "shell:priv-lvl=15" > > The question was why you need to use IPA as a storage for profiles? > It looks like you are not using FreeRADIUS. Is this the case? I already answered him privately. He is using FreeRADIUS and wants to use IPA's ldap for performing lookup's inside radiusd in order to add an attribute to the AccessAccept reply. Radius profiles in LDAP are one way to do this, but it means adding schema to 389ds. My suggestion is to use IPA's ability to put users into groups. Then in FreeRADIUS's unlang policy language use the group to add the attribute to the reply. Something along the lines of this in the post-auth section should do the trick (not 100% sure it's correct syntax): post-auth { if(Ldap-Group == "xxx") { update reply { cisco-avpair = "shell:priv-lvl=15" } } } You'll need to lookup the group in the authorize section with a search crafted for IPA. If there are a lot of different reply attributes this becomes cumbersome and some type of extra schema would be needed, but if there are only a handful of attributes putting it in the radius config is reasonable. -- John ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Elliptic curves with the CA
On 09/18/2013 01:53 PM, mees virk wrote: > I do not have a valid support contract, or other contracts with RedHat. > Doesn't that stop me from opening proper RFE ticket? > > In any case, my interest was this time solely for evaluation purposes. > If I were actively choosing an integrated identity management product, I > might not choose Freeipa because it takes the longevity of the product > and the development stance (lack of roadmap?) into question. > > RSA is slowly getting into slippery slope, because it really isn't about > what it's worth today. When you protect something with a cryptographic > algorithm you have to take account for how long certain types of data > will be stored, and factor that time frame in. Increasing the key sizes > will not be solution, because several embedded devices such as VPN > products, smartcards and RFID devices will start failing pretty fast > after 1024-2048 bit keys. > > ECC was designed to solve some of these issues; it's important > development not mostly because of security today but because it will > scale better up (it was designed to be implementable better on > hardware), and the key sizes start from nicer point of security vs size. > So it's the feature that would future proof the CA. At this moment there > is available ECC support on some products on all the areas such as smart > cards, so the products not having that option out of the box will start > basically losing in the competition. > > I'm not trying to make a technical point here (if I made some minor > error there, sorry) but a managerial, and from product management > viewpoint. ECC must be on the feature set, or the CA features will be > discarded in the future by potential users. That means the Freeipa as a > whole might not be selected for some projects. Plus, it doesn't really > hurt having ECC in. :) Yes we understand these issues. IPA is designed for longevity. EC is still very new, there are many components on which IPA depends which have to gain EC support before IPA can offer it, that is work which is actively in progress. There are still some intellectual property questions which are under consideration with respect to EC. And there has to be demand to support EC in IPA otherwise other RFE's and bug's will take precedence. The short story is EC is emerging, we comprehend it's value and it will almost certainly appear at some point in IPA in some form. Please do file an RFE. -- John ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Changing the WebUI idiom
On 09/23/2013 07:19 AM, Arturo Borrero wrote: > Hi there! > > FreeIPA WebUI in spanish has some annoyances in how the text is showed. > > http://img545.imageshack.us/img545/9016/9eur.png > > We would like to switch from spanish to standar english in the WebUI. > > Could anyone please point me in the right direction about changing that? Changing the language preference in your browser should accomplish that. In Firefox open the preferences dialog and select languages under Content. -- John ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Changing the WebUI idiom
On 09/23/2013 07:55 AM, John Dennis wrote: > On 09/23/2013 07:19 AM, Arturo Borrero wrote: >> Hi there! >> >> FreeIPA WebUI in spanish has some annoyances in how the text is showed. >> >> http://img545.imageshack.us/img545/9016/9eur.png >> >> We would like to switch from spanish to standar english in the WebUI. >> >> Could anyone please point me in the right direction about changing that? > > Changing the language preference in your browser should accomplish that. > In Firefox open the preferences dialog and select languages under Content. Oh by the way, you could help us and file a bug on the spanish translation so we can get the translation fixed. -- John ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] External CA
On 11/08/2013 04:56 AM, Petr Viktorin wrote: > On 11/08/2013 09:01 AM, Martin Kosek wrote: >> Thanks for heads up. You mean by the difference between "O=MW" and >> "O=MELTWATER.COM"? >> Petr, is this possible? Can it be validated in the the installer if this is >> the >> root cause? Thats a good question. Typically with cert validation only the CN component in the subject is cross checked. More aggressive validators are free to examine all RDN's in the subject (not sure what the PKIX behavior is with respect other RDN's). Of course this isn't cert validation but validating a CSR is closely related. The first place I would look is the Dogtag policy. > It is possible. It's hard to tell without the logs; looks like the > failure was inside Dogtag. There may be more issues; for instance I > don't think we considered PEM files with extra data before the BEGIN > CERTIFICATE. > I filed a ticket to investigate: > https://fedorahosted.org/freeipa/ticket/4019 FWIW I've authored a set of Python utilities to work with pem files for OpenStack. They work just fine with PEM blocks embedded with non-PEM text. I was thinking the utilities would also be useful in FreeIPA (in fact my experience in IPA is what guided the development of these utilities. I'll try to get them up in a git repo shortly and send a pointer. -- John ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] External CA
On 11/08/2013 08:53 AM, John Dennis wrote: > FWIW I've authored a set of Python utilities to work with pem files for > OpenStack. They work just fine with PEM blocks embedded with non-PEM > text. I was thinking the utilities would also be useful in FreeIPA (in > fact my experience in IPA is what guided the development of these > utilities. I'll try to get them up in a git repo shortly and send a pointer. Done. git clone git://fedorapeople.org/~jdennis/utilities.git Look in the x509 subdirectory, there are also unittests for both modules. -- John ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Installation issues with sub-ca.
On 11/12/2013 11:36 AM, Rob Crittenden wrote: > This is basically what I saw too. I'm waiting on someone from the NSS > team to get back to me. This must have something to do with the way that > OpenSSL validates certs vs NSS. Apparently NSS is being more picky but I > don't know why yet. FWIW the current version of python-nss allows you to run NSS cert validation in logging mode, you'll get back a list of errors detailing everything NSS found at fault. Now having said that I'll also note the validation information NSS generates can sometimes be less than wonderful, but at least you'll be getting an insight into where NSS is finding fault. There is an example Python script doc/examples/verify_cert.py which you can run to validate a cert, you can turn on the validation logging with the --log command line arg. The example script also illustrates how to do cert validation logging. The script is contained in the python-nss-doc subpackage. You'll need to running python-nss >= 0.14. -- John ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Installation issues with sub-ca.
On 11/14/2013 03:29 AM, Andrea Bontempi wrote: > I did some tests: The error occurs when I use a CA managed by EJBCA, > if I use a CA generated by openssl or nss everything works properly. > > The problem is that i can't reproduce the bug in an external nss > db... but maybe I don't follow the same steps that uses the > installation script. Do we have a copy of the sub-CA cert and the CA cert which we can examine? There are a variety of rules (primarially in the cert extentions) which can cause validation failure if the extensions are not as expected. My guess is you've got something specified in the extensions which is unanticiapated or incorrect. -- John ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Installation issues with sub-ca.
On 11/14/2013 08:56 AM, Rob Crittenden wrote: > Andrea Bontempi wrote: >>> This is incorrect. To validate a certificate you only need the CA public >>> keys, not the private ones. Only having the ipa-ca-agent key is right. >>> This is a temporary database, not the CA database. We are using this >>> cert to request some information about itself from the CA in this case. >> >> You're right, I thought that the script use a temporary db to create the >> final database, but it's only to connect with sslget. >> >>> I think there is an issue with one of the CA certs but I've yet to >>> duplicate it or identify what is wrong. I'm still waiting on word back >>> from one of the NSS devs. >> >> >> I did some tests: The error occurs when I use a CA managed by EJBCA, if I >> use a CA generated by openssl or nss everything works properly. >> >> The problem is that i can't reproduce the bug in an external nss db... but >> maybe I don't follow the same steps that uses the installation script. > > The problem has to do with the encoding of the subject and issuer fields. > > The issue is one is encoded as a UTF8 string and the other is > encoded as a printable string. This makes the binary derSubject and > derIssuer fields different. NSS does not like derSubject and derIssuer > fields that are different Good information! But this sounds like a bug to me if NSS is comparing binary data for equality, one should decode the binary encoding to arrive at a canonical form and then compare the canonical form, right? -- John ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Clarification about FreeIPA milestones
On 08/06/2011 04:43 AM, Ian Stokes-Rees wrote: On 8/6/11 4:29 AM, Dmitri Pal wrote: IPA 2.1 is getting close to its release so it is time to set some expectations and explain our roadmap moving forward a little bit. First it is planned to have couple bug fixing iterations on top of 2.1. That translates into 2.1.1 and 2.1.2 milestones respectfully. We do not plan to do any point releases after 2.1 on the same code base. We will maintain this code for some time doing fixes and back porting from the tip but we do not plan to have 2.2 release from it. The next release will be a major release. It will be 3.0. Can you clarify from your comments about "not from the same code base" if you mean v3.0 will be yet another re-write as v2.0 was? The comment refers to our source code branching, 2.1 is being frozen. There are no plans for a rewrite, just incremental improvements and feature additions. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] ETA on the libcurl fix?
I believe the fix was incorporated into this RPM, curl-7.21.3-9.fc15 and was pushed into the stable update at 2011-08-09 01:29:07 xmlrpc-c is dependent on libcurl and is utilized by IPA. I do not believe there is new version of xmlrpc-c built against the fixed libcurl as of yet but we're expecting it shortly. I would recommend you install the new curl version from F15 updates and I'll appraise you of the status of xmlrpc-c in the morning. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] ETA on the libcurl fix?
On 08/09/2011 12:06 AM, John Dennis wrote: I believe the fix was incorporated into this RPM, curl-7.21.3-9.fc15 and was pushed into the stable update at 2011-08-09 01:29:07 xmlrpc-c is dependent on libcurl and is utilized by IPA. I do not believe there is new version of xmlrpc-c built against the fixed libcurl as of yet but we're expecting it shortly. It looks like the fix for xmlrpc was applied and built in version xmlrpc-c-1.25.1-1501.svn2077.fc15 built in Koji at 2011-02-08 07:52:36. However that build has not been pushed to Bohdi yet so it's not in an update channel yet, I'll investigate why. I would recommend you install the new curl version from F15 updates and I'll appraise you of the status of xmlrpc-c in the morning. I perhaps may have spoken too hastily by recommending you upgrade curl. I'm trying to remember your exact situation, if you downgraded the offending packages and regained a working system via the downgrade you should kept that configuration until both curl and xmlrpc-c are available since they are co-dependent. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] freeRADIUS?
On 10/04/2011 10:50 AM, Jimmy wrote: I've been searching and see a few references to freeRADIUS used with FreeIPA, but I don't see any substantial information on the subject. Is there a procedure to use FreeIPA with freeRADIUS? I have a standalone openldap/freeradius server that I would like to eliminate if possible. Integrating FreeRADIUS with IPA is on the long term roadmap. It's not as easy as one might imagine. The fundamental problem is that many of the RADIUS authentication methods require access to the user's cleartext password or hashes we feel are insecure. This presents a design issue for us to resolve, as such it has been pushed out. Refer to this chart for more information: http://deployingradius.com/documents/protocols/compatibility.html -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] freeRADIUS?
On 10/05/2011 09:44 AM, Dmitri Pal wrote: On 10/04/2011 11:14 AM, John Dennis wrote: On 10/04/2011 10:50 AM, Jimmy wrote: I've been searching and see a few references to freeRADIUS used with FreeIPA, but I don't see any substantial information on the subject. Is there a procedure to use FreeIPA with freeRADIUS? I have a standalone openldap/freeradius server that I would like to eliminate if possible. Integrating FreeRADIUS with IPA is on the long term roadmap. It's not as easy as one might imagine. The fundamental problem is that many of the RADIUS authentication methods require access to the user's cleartext password or hashes we feel are insecure. This presents a design issue for us to resolve, as such it has been pushed out. Refer to this chart for more information: http://deployingradius.com/documents/protocols/compatibility.html OK. This could have created a wrong impression the freeRADIUS can't be used now with IPA. This is wrong. There is no tight integration but IPA for sure can act as an "authentication oracle" for freeRADIUS. http://deployingradius.com/documents/protocols/oracles.html You have to use: EAP-TTLS as an outer tunnel, PAP as an inner tunnel and configure freeRADIUS to do bind operation against IPA as if it is an LDAP server (or you can use pam for that if you want, with SSSD you might get offline caching if you connection between RADIUS host and IPA might be disrupted, but if they are on the same box or connection is reliable it might make sense to use direct ldap bind rather than use the PAM stack) . How to do all this can be found in the RADIUS manual. If you find some interesting gotchas related to IPA or SSSD in this setup please share with us. Also if you find this information not sufficient let us know and we will try to help you find the right documentation. Sure, but the typical stumbling block is that in the majority of cases the goal is transparent wireless authentication by supplicants in their default configuration. It's usually difficult to get users to properly configure their supplicants and for some versions of Windows it may not be possible at all without installing a different supplicant. Then there is is the issue of getting the radius CA cert into each client or telling users to disable cert validation which is not something we should be doing. In short, there are logistical problems which may not meet real world needs. It's hard to know a prori if the above will meets the needs or not, perhaps it will so it's good Dmitri posted the suggestion. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Delete host: Unable to communicate with CMS (Not Found)
On 11/17/2011 11:25 AM, Adam Young wrote: To summarise, the errors are: SEVERE: Error initializing socket factory java.lang.ClassNotFoundException: org.mozilla.jss.ssl.SSLSocket SEVERE: Failed to initialize connector [Connector[HTTP/1.1-9443]] java.io.IOException: Failed to access resource /WEB-INF/lib/osutil.jar I'd guess that this means I'm missing a package? I'm having trouble figuring out which one contains the code I'm missing. Maybe I need to reinstall one? Is this on F16? It might be that the package is there but not being picked up. JSS and osutils are a JNI packages, and you should find them in /usr/lib64/java/jss4.jar and osutil.jar, but they might end up in /usr/lib/java/jss4.jar and osutil,jar My guess is this is due to the fact these jars changed their location. The symlinks to the jars are established by pkicreate. We have a bug open to enchance pkicreate (or add a new tool) which will adjust the links after an upgrade (sorry don't recall the bz number off the top of my head, could did it up if necessary). You can cd to /var/lib/pki-ca and do an ls -l on common/lib and webapps/ca/WEB-INF/lib/ and inspect the symbolic links to see if any are dangling. If so adjust the link to point to it's new location. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Delete host: Unable to communicate with CMS (Not Found)
On 11/17/2011 11:46 AM, Dan Scott wrote: On Thu, Nov 17, 2011 at 11:35, John Dennis wrote: On 11/17/2011 11:25 AM, Adam Young wrote: To summarise, the errors are: SEVERE: Error initializing socket factory java.lang.ClassNotFoundException: org.mozilla.jss.ssl.SSLSocket SEVERE: Failed to initialize connector [Connector[HTTP/1.1-9443]] java.io.IOException: Failed to access resource /WEB-INF/lib/osutil.jar I'd guess that this means I'm missing a package? I'm having trouble figuring out which one contains the code I'm missing. Maybe I need to reinstall one? Is this on F16? It might be that the package is there but not being picked up. JSS and osutils are a JNI packages, and you should find them in /usr/lib64/java/jss4.jar and osutil.jar, but they might end up in /usr/lib/java/jss4.jar and osutil,jar My guess is this is due to the fact these jars changed their location. The symlinks to the jars are established by pkicreate. We have a bug open to enchance pkicreate (or add a new tool) which will adjust the links after an upgrade (sorry don't recall the bz number off the top of my head, could did it up if necessary). You can cd to /var/lib/pki-ca and do an ls -l on common/lib and webapps/ca/WEB-INF/lib/ and inspect the symbolic links to see if any are dangling. If so adjust the link to point to it's new location. Success! Thanks so much. /var/lib/pki-ca/common/lib/jss4.jar /var/lib/pki-ca/webapps/ca/WEB-INF/lib/osutil.jar /var/lib/pki-ca/webapps/ca/WEB-INF/lib/symkey.jar Were all broken, pointing into /usr/lib/. Changing them to link to /usr/lib64 allowed pki to start properly and I can make changes to the host entry. It sounds like you have a fix for this in progress, or do I need to file a bug? Found the bugzilla, it's https://bugzilla.redhat.com/show_bug.cgi?id=728598 It's filed against Red Hat Certificate System in RHEL, not dogtag in Fedora. Adam do you want to clone it into Fedora? -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Delete host: Unable to communicate with CMS (Not Found)
On 11/17/2011 01:40 PM, Alexander Bokovoy wrote: On Thu, 17 Nov 2011, John Dennis wrote: My guess is this is due to the fact these jars changed their location. The symlinks to the jars are established by pkicreate. We have a bug open to enchance pkicreate (or add a new tool) which will adjust the links after an upgrade (sorry don't recall the bz number off the top of my head, could did it up if necessary). You can cd to /var/lib/pki-ca and do an ls -l on common/lib and webapps/ca/WEB-INF/lib/ and inspect the symbolic links to see if any are dangling. If so adjust the link to point to it's new location. Success! Thanks so much. /var/lib/pki-ca/common/lib/jss4.jar /var/lib/pki-ca/webapps/ca/WEB-INF/lib/osutil.jar /var/lib/pki-ca/webapps/ca/WEB-INF/lib/symkey.jar Were all broken, pointing into /usr/lib/. Changing them to link to /usr/lib64 allowed pki to start properly and I can make changes to the host entry. It sounds like you have a fix for this in progress, or do I need to file a bug? Found the bugzilla, it's https://bugzilla.redhat.com/show_bug.cgi?id=728598 It's filed against Red Hat Certificate System in RHEL, not dogtag in Fedora. Adam do you want to clone it into Fedora? I'll add symlinks update into freeipa F15->F16 upgrade script. At worst, if 728598 will be fixed in Fedora as well, that part of the code will do nothing. Tickets 2103 and 2117 in upstream FreeIPA are for tracking that. Just one thing to be careful of, you want to make sure the link points to the preferred entry in the filesystem. What do I mean by that? There are unversioned names in /lib which are links to the versioned entry, the preferred name is the unversioned link name. There may be similar redirection occurring for mulit-lib, see below. Where am I going with this? A few months ago there was a lot of back and forth discussion over where and how jni jars (those which have arch specific components) would be named and located to accmodate multi-lib. I don't recall how the Fedora java-sig folks finally resolved this issue, mharmsen (Matt) would probably know as he responsible for the packaging of these components and is the person who moved them, the aforementioned bz is also assigned to Matt. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Fwd: manual client join
On 12/18/2011 09:05 PM, Stephen Ingram wrote: On Mon, Dec 5, 2011 at 12:49 PM, Rob Crittenden wrote: ...snip... Be sure that the CN value is the FQDN of your server. IPA server: # ipa cert-request --prinicipal HTTP/remote.example.com /path/to/csr.pem # ipa service-show --out=/tmp/service.crt HTTP/remote.example.com Your cert will be in /tmp/service.crt and PEM formatted for easy use. The output of cert-request is just a base64 blob. ...snip... This may be handy to augment the IPA documentation too if you want to donate back your findings :-) OK, I'm going through lots of different scenarios to try to document this entire process and ran into one problem so far. Using your suggested command above to retrieve the cert via the command line: ipa service-show --out=/tmp/service.crt HTTP/remote.example.com This does not work for the host certficiate: e.g. ipa service-show --out=/tmp/service.crt host/remote.example.com While it is now easy to get the PEM formatted cert from the UI in version 2.1.4, I don't see any way to obtain this particular cert from the command line other than ipa cert-show {serial number} which is obviously not very convenient. Is there another way I'm missing or is that it? Sorry, but currently on the command line the only way to specify a certificate is via it's serial number. The serial number is the only identifier guaranteed to be unique. However, I agree it's not convenient. Would you like to open an RFE (Request for Enhancement) on https://fedorahosted.org/freeipa/ -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] PEM and DER certificate formats
On 01/06/2012 04:45 PM, Stephen Ingram wrote: I noticed a message on here some time ago about changing IPA to output certificates in PEM format instead of DER. I see that in version 2.1.4, the UI does indeed output in PEM format. It appears as though the CLI still outputs in DER. Is this the case? I agree that PEM is certainly more typical, however, when working with the Java keystore, it asks for DER format. Should I still be able to get that from IPA or should I just use openssl to convert it? It's much better to use PEM format, it's portable and accepted by all PKI software. The --out option of cert_show command line writes the cert in PEM format to a file. Thus both the web UI and the command line both now support PEM. Not sure about the Java keystore, I would expect it should accept either DER or PEM but if indeed it only support DER then it's trival to convert PEM to DER. There should be an existing utility to do it. If not it's as simple as taking the text between the PEM delimiters and base-64 decoding it. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] PEM and DER certificate formats
On 01/06/2012 04:55 PM, Rob Crittenden wrote: The cli outputs a base64 blob of data. Yes, it output a base64 blob to stdout. But that base64 blob is completely non-standard as an exchange format, it's just a textual encoding of the binary DER data. However the cli can write PEM format to a file using the --out option. PEM is standard and you should have no problems finding code that accepts PEM. I would strongly suggest you stick to standard PEM and use utilities to convert it to DER only if the software you're importing it is borked and can't accept PEM. If you took that and ran it through a base64 decoder you'd have DER format. You can't get DER directly right now. We could probably add an option to write a file in DER format if you wanted to open an RFE on our trac instance. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] FreeIPA 2.2 alpha or beta available somewhere?
On 02/10/2012 02:22 PM, Marco Pizzoli wrote: I wget-ed the repo file on a 64bit fedora16 system but I'm failing in seeing the package for 64-bit systems. Please, could you tell me what my error is? We just finished rebuilding the repo. Please try again. We don't have a mechanism to lock the repo while it's being populated so on occasion you may see some odd failures if you happen to hit it while it's updating. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] FreeIPA 2.2 alpha or beta available somewhere?
On 02/10/2012 02:35 PM, Marco Pizzoli wrote: No, same as before. Is it "yum makecache" sufficient to renew my metadata? Sounds like it should work, I'm not in the habit of using makecache, I tend to use the big hammer 'yum clean --all' I just checked the repo the files are there, so I assume yum is somehow confused. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] FreeIPA 2.2 alpha or beta available somewhere?
On 02/10/2012 03:49 PM, Marco Pizzoli wrote: --> Finished Dependency Resolution *Error: Protected multilib versions: libldb-1.1.0-1.fc16.i686 != libldb-1.1.4-1.fc16.1.x86_64* This error is because you've got both a 32-bit and 64-bit version of libldb installed, note how the 32-bit version is 1.1.0 and the 64-bit version is 1.1.4, they're not the same. However the ipa-devel repo does have both the 32-bit and 64-bit version of 1.1.4 available in the x86-64 repo ipa-devel/fedora/16/x86_64/os/libldb-1.1.4-1.fc16.1.i686.rpm ipa-devel/fedora/16/x86_64/os/libldb-1.1.4-1.fc16.1.x86_64.rpm So the repo looks good, not sure what yum is complaining about, it should see both 32-bit and 64-bit is available for version 1.1.4 and install both, unless of course you've got a dependency on the 1.1.0 32-bit version, but yum should tell you that. That's about as much help as I can give you at the moment. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Future audit feature
On 02/13/2012 09:14 AM, Marco Pizzoli wrote: Hi guys, I'm interested to know what is the expected feature that I have to expect from the Audit part of IPA. I had a look at this: http://www.freeipa.org/page/Audit_Design_Overview I see that are mentioned watchers on directories for alerting on file alterations. What is the final high-level purpose? I suppose not only anti tampering... The audit portion of IPA has been put on hold while we focus on on the core identity and policy components. A significant part of the audit component was collecting log information from all services on a host and aggregating them on a central server for analysis and archiving. The directory watching you saw on the aforementioned page is exactly for the purposes of watching log file manipulation. There has been a *lot* of recent discussion on how to perform logging in the larger community as well as capturing auditable system events. As yet there hasn't been a consensus. Until such time as a consensus forms around the methods, tools, and libraries in this domain we won't proceed further with the A part of IPA. However, we are actively participating in these discussions. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Strange klist output
On 02/25/2012 07:53 AM, Marco Pizzoli wrote: Hi, as you know I'm working with FreeIPA 2.1.90. By following documentation I checked my tickets by issuing the klist command but I'm obtaining an output slightly different than the one on the doc. [root@freeipa01 ~]# klist -kt /etc/krb5.keytab Keytab name: WRFILE:/etc/krb5.keytab KVNO Timestamp Principal - 2 02/15/12 18:28:58 host/freeipa01.unix.mydomain...@unix.mydomain.it <mailto:freeipa01.unix.mydomain...@unix.mydomain.it> 2 02/15/12 18:28:58 host/freeipa01.unix.mydomain...@unix.mydomain.it <mailto:freeipa01.unix.mydomain...@unix.mydomain.it> 2 02/15/12 18:28:58 host/freeipa01.unix.mydomain...@unix.mydomain.it <mailto:freeipa01.unix.mydomain...@unix.mydomain.it> 2 02/15/12 18:28:58 host/freeipa01.unix.mydomain...@unix.mydomain.it <mailto:freeipa01.unix.mydomain...@unix.mydomain.it> 2 02/15/12 18:28:58 host/freeipa01.unix.mydomain...@unix.mydomain.it <mailto:freeipa01.unix.mydomain...@unix.mydomain.it> 2 02/15/12 18:28:58 host/freeipa01.unix.mydomain...@unix.mydomain.it <mailto:freeipa01.unix.mydomain...@unix.mydomain.it> I see 6 rows as duplicated. Is it normal? Please, could you explain what is happening? I believe that is due to the new s4u2proxy kerberos implmentation, I've seen it too while testing with s4u2proxy. Unfortunately I cannot explain it either and would love for one of our Kerberos gurus to provide an explanation. John -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Strange klist output
On 02/25/2012 09:20 AM, Simo Sorce wrote: Use -e to see what enctypes are reported. Is this difference in any way related to s4u2proxy or did the extra enctypes show up because we upgraded Kerberos and picked up other unrelated behavior at the same time. Why do we now have all these enctypes? Is it to satify forwarding/proxy when you don't know a prori which enctype the foreign endpoint will require? -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Strange klist output
On 02/25/2012 09:40 AM, Simo Sorce wrote: Why do we now have all these enctypes? Is it to satify forwarding/proxy when you don't know a prori which enctype the foreign endpoint will require? Because in kerberos each principal can have multiple keys, generally one per supported (by the KDC) enctype. This is so that a client can use the strongest enctype it has crypto support for. Sure, that makes sense. But this is new behavior, what changed? -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] devel repo
On 02/28/2012 12:25 AM, Brian Cook wrote: Hi, I've added the devel repo at http://jdennis.fedorapeople.org/ipa-devel/fedora/$releasever/$basearch/os/ to my F16 install. When listing the pkgs in the repo I only get i686 arch for freeipa-server. I can see the x86_64 pkg in the repo if I browse it. Is this the right repo to use for testing patches that were recently committed, and is the repo metadata up to date? Did you install this? The Fedora repo config file can be downloaded here: http://jdennis.fedorapeople.org/ipa-devel/ipa-devel-fedora.repo If so you should be getting x86_64 packages if your system is configured for it. Yes, it the right place to find up to the minute builds with recent fixes and enhancements (and possibly some instability). New builds occur as soon as they are committed to the source code repository. Each the repo is updated an email is sent to the ipa-and-samba-team-automation list, you can subscribe if you wish. Archives of the automation list can be found here: http://post-office.corp.redhat.com/archives/ipa-and-samba-team-automation -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Constantly failing ipa-client-install
On 03/24/2012 01:11 PM, Marco Pizzoli wrote: Hi guys, I'm wirking with 2.1.90-rc1 and I'm getting always this error during a client enrollment: [root@myhostname ~]# ipa-client-install --enable-dns-updates --principal=admin --password=mypassword --ssh-trust-dns --mkhomedir Discovery was successful! Hostname: myhostname.server.unix.mydomain.it <http://myhostname.server.unix.mydomain.it> Realm: UNIX.MYDOMAIN.IT <http://UNIX.MYDOMAIN.IT> DNS Domain: unix.mydomain.it <http://unix.mydomain.it> IPA Server: freeipa01.unix.mydomain.it <http://freeipa01.unix.mydomain.it> BaseDN: dc=unix,dc=mydomain,dc=it Continue to configure the system with these values? [no]: yes Synchronizing time with KDC... Enrolled in IPA realm UNIX.MYDOMAIN.IT <http://UNIX.MYDOMAIN.IT> Created /etc/ipa/default.conf Traceback (most recent call last): File "/usr/sbin/ipa-client-install", line 1527, in sys.exit(main()) File "/usr/sbin/ipa-client-install", line 1514, in main rval = install(options, env, fstore, statestore) File "/usr/sbin/ipa-client-install", line 1327, in install api.finalize() File "/usr/lib/python2.7/site-packages/ipalib/plugable.py", line 659, in finalize self.__do_if_not_done('load_plugins') File "/usr/lib/python2.7/site-packages/ipalib/plugable.py", line 452, in __do_if_not_done getattr(self, name)() File "/usr/lib/python2.7/site-packages/ipalib/plugable.py", line 598, in load_plugins self.import_plugins('ipalib') File "/usr/lib/python2.7/site-packages/ipalib/plugable.py", line 649, in import_plugins raise e ImportError: No module named krbV Could you help me? Thanks as usual Marco Sounds like you don't have the python-krbV RPM installed. $ sudo yum install python-krbV should fix it. What version of freeipa-client do you have? $ rpm -q freeipa-client Does it require python-krbV? rpm -q --requires freeipa-client I think we might have introduced a dependency on python-krbV in the client code we weren't aware of and need to fix this. If that's true would you please file a bug here: https://fedorahosted.org/freeipa/ -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] firefox on windows how to get a kerberos ticket?
What are you trying to accomplish? In IPA 2.2 you can log onto the web UI without a kerberos ticket by using password based auth, thus the web UI no longer requires a kerberos ticket. This applies only to the web UI, not other IPA components (at the moment). John -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] firefox on windows how to get a kerberos ticket?
On 04/03/2012 05:58 PM, Steven Jones wrote: So how do I login without a kerberos ticket? See attached screenshot snippets From: John Dennis [jden...@redhat.com] Sent: Wednesday, 4 April 2012 9:52 a.m. To: Steven Jones Cc: Petr Spacek; freeipa-users@redhat.com Subject: Re: [Freeipa-users] firefox on windows how to get a kerberos ticket? What are you trying to accomplish? In IPA 2.2 you can log onto the web UI without a kerberos ticket by using password based auth, thus the web UI no longer requires a kerberos ticket. This applies only to the web UI, not other IPA components (at the moment). -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ <><>___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] 2 things,
On 04/03/2012 07:04 PM, Steven Jones wrote: how do I logout, ie make my sessions expire so I can login as someone else? Once you are logged in you will see in the upper right hand corner of every page something that says "logged in as " and right next to it is a a clickable item "logout". Click on the logout and you will be logged out and then you can log back in as someone else. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] 2 things,
On 04/03/2012 09:17 PM, Steven Jones wrote: My gui doesnt have the "logout" button. :( It will :-) It's a new feature, currently in beta. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] IPv6
On 04/27/2012 04:45 AM, Petr Spacek wrote: On 04/26/2012 11:42 PM, Simo Sorce wrote: On Thu, 2012-04-26 at 21:18 +, Steven Jones wrote: Hi, FYI, I shutdown IPv6 as we dont do IPv6 and found that IPA wouldnt workslight oops there... Hi Steve, can you be more explicit on how you 'shutdown' IPv6 ? And can you please tell exactly how IPA breaks in that case ? Is this after IPA is fully installed ? Or does the installer fail ? Simo. Is it same issue as described in https://www.redhat.com/archives/freeipa-users/2012-April/msg00160.html ? We do IPv6 in several places, but a while ago I noticed the way we iterate over address families in nsslib in conjunction with getaddrinfo (the io.AddrInfo class) looks dubious, it seems overly complex as if it's trying to force a family selection (not sure, I would have to go back and really look at the code again). In any event getaddrinfo is designed to return a list of possible addresses sorted in priority order by the system. You're supposed to start at the first address in the list and see if you can connect, if not try the next address. You're not supposed to take addresses in the list based on some other criteria (which is what we seem to be doing with the family). FWIW, the raw c lib getaddrinfo allows one to specify constraints (such as family), unfortunately NSPR (the wrapper around getaddrinfo in nsslib) does not permit this, not sure why (probably because NSPR has to fallback to other mechanisms if getaddrinfo is not available) -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] IPv6
On 04/30/2012 03:54 AM, Petr Spacek wrote: On 04/27/2012 02:43 PM, John Dennis wrote: On 04/27/2012 04:45 AM, Petr Spacek wrote: On 04/26/2012 11:42 PM, Simo Sorce wrote: On Thu, 2012-04-26 at 21:18 +, Steven Jones wrote: Hi, FYI, I shutdown IPv6 as we dont do IPv6 and found that IPA wouldnt workslight oops there... Hi Steve, can you be more explicit on how you 'shutdown' IPv6 ? And can you please tell exactly how IPA breaks in that case ? Is this after IPA is fully installed ? Or does the installer fail ? Simo. Is it same issue as described in https://www.redhat.com/archives/freeipa-users/2012-April/msg00160.html ? We do IPv6 in several places, but a while ago I noticed the way we iterate over address families in nsslib in conjunction with getaddrinfo (the io.AddrInfo class) looks dubious, it seems overly complex as if it's trying to force a family selection (not sure, I would have to go back and really look at the code again). Family selection should not be enforced from our code, I think. This way can create hidden dependency based on our (probably wrong) assumptions. Agreed. We should not try to influence family selection. I will open an IPA trac ticket. In any event getaddrinfo is designed to return a list of possible addresses sorted in priority order by the system. You're supposed to start at the first address in the list and see if you can connect, if not try the next address. You're not supposed to take addresses in the list based on some other criteria (which is what we seem to be doing with the family). FWIW, the raw c lib getaddrinfo allows one to specify constraints (such as family), unfortunately NSPR (the wrapper around getaddrinfo in nsslib) does not permit this, not sure why (probably because NSPR has to fallback to other mechanisms if getaddrinfo is not available) AFAIK "right place" to specify this kind of constraints is to use "/etc/gai.conf" configuration file. NSPR ignores it? No. I believe /etc/gai.conf will be respected on modern systems with getaddrinfo support by NSPR because NSPR calls into getaddrinfo which is influenced by /etc/gai.conf. What I was referring to is that getaddrinfo exposes network address selection filtration based on gai.conf (or so I believe). -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] IPv6
On 04/30/2012 08:27 AM, John Dennis wrote: Agreed. We should not try to influence family selection. I will open an IPA trac ticket. https://fedorahosted.org/freeipa/ticket/2695 -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Does FreeIPA support web services SSO gracefully?
On 05/04/2012 11:26 AM, Rob Crittenden wrote: Firefox needs to be configured to be allowed to perform Kerberos SSO in a domain. FreeIPA 2.2 introduced a forms-based login so you don't have to fall back to basic authentication (with KrbMethodK5Passwd on). The forms based login applies to the IPA Admin console, the OP was asking web services other than the IPA admin console, therefore that's not relevant. What is relevant is getting the other web services to use kerberos negotiate auth instead of whatever they are currently using. The difficulty of that task really depends on the particular web service. The user must also be able to acquire a kerberos ticket. So the answer to the OP is, if you can satisfy the following two conditions then IPA is a graceful solution: 1) The web service can be configured to use kerberos negotiate auth. 2) Each of your users has a facility available to acquire a kerberos ticket. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] FreeIPA and others
On 05/11/2012 02:18 PM, Chandan Kumar wrote: Hi All, I was considering different centralized authentication/authorization services such as FreeIPA, 389 and Open ldap to deploy into our network in order to have a good centralized user authentication/authorization machanism. I was wondering what are they key that FreeIPA provides as compared to other directory servies in terms of extra feature, ease of deployment and use etc. FreeIPA is an integrated solution that includes DNS, kerberos SSO, host management, HBAC, role based authorization, integration with SSSD, sophisticated group management, sudo support, certificate management, can replace NIS and netgroups, supports replication for redundant servers, etc. It supports both a scriptable command line utility set as well as a web based GUI. The next version will include support for cross realm trusts allowing for powerful integration with Active Directory. FreeIPA is built on top of 389 DS, MIT Kerberos KDC and the Dogtag certificate management system. Openldap is well, just an LDAP server (some assembly required). The whole idea of FreeIPA is to take the basic primitive services supplied by an LDAP server but make it vastly more powerful by layering a lot of sophisticated functionality on top it which is fully integrated and easy to use. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] FreeIPA and others
On 05/11/2012 03:51 PM, Chandan Kumar wrote: Thanks John for reply. Ok. So basically it integrate various subsystems required to have a full fledged AAA system and give the end user a single controlling interface to control various components. Excellent summary. So will its webgui enable to control 389, Krb and Radius configurations too? The web gui controls 389 and KRB configuration and the data those services operate on. We currently do not support radius, however it's on the roadmap. A fundamental problem with radius is many of the authentication protocols used in radius require access to a cleartext password or hash. So far we've been assiduous in not storing and exposing this material for security reasons. There are possible solutions but we've decided there are more import features to address first. Because if I see each of these components individually each needs to be setup separately with lot of pain. Absolutely, the pain threshold of setting those component up and getting them to play together is high. One of the primary design goals of FreeIPA is to eliminate those pain points so you can focus on administrating your user base. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] 2.20 dirsrv memory usage
On 07/17/2012 05:43 PM, Stephen Ingram wrote: > [ details of performance analysis snipped for brevity ] I wonder if we shouldn't add some timing metrics to our code. As it is it's very hard to know where time is being spent. When I wrote the session code I added some timestamps used for managing session timeouts. It wouldn't be too hard to expand this to time how long it takes a command to execute because it's evaluated for every command. Combined with timestamping in the UI code we could get a reasonable idea of where some bottlenecks lie (or don't). -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] 2.20 dirsrv memory usage
On 07/18/2012 02:59 PM, Stephen Ingram wrote: On Wed, Jul 18, 2012 at 6:45 AM, Petr Vobornik wrote: On 07/17/2012 11:43 PM, Stephen Ingram wrote: 8><-- I'm beginning to think this is just the Web UI itself instead of 389 although it is really difficult to tell. I've poured over the debug logs and didn't see anything that caused me concern. It's certainly usable, but I just got really spoiled by the unbelievable quickness of 2.1.3. When your release notes indicate it should be faster, what are you comparing it to? Maybe this only happens with upgraded instances and not fresh installs. It is always possible something didn't get upgraded properly but I've done 2.1.3 -> 2.2.0 upgrades and haven't seen this. When we say something is faster we're always referring to the previous version (or versions). Maybe I was just lucky with 2.1.3. On a first load it might take some time to load the "frame" as I call it. But the data would load almost instantaneously from there (certainly no more than 1 s) as you moved from page to page. Here, even if I return to the same page, the system acts as if the data is begin fetched for the very first time as it is no faster than the first load. Maybe that is significant to the problem? I think the culprit is Web UI paging capabilities introduced in 2.2. With lot of users, responses might grow in size. You can check their size and duration in browser developers tools. I suggest chrome/chromium - press F12 and choose 'network' tab. This new feature can't be disabled in configuration. To test if the slowdown is done by paging you can (at own risk) replace line /usr/share/ipa/ui/facet.js:538 that.pagination = spec.pagination === undefined ? true : spec.pagination; with: that.pagination = false; Note: It will break some other parts of the UI - so for testing only. I've made the substitution in the code (was line 507 for me-do I have a different version?). Looking at the time chart in Chrome I see that the bulk of the time is for /ipa/session waiting. Would "waiting" mean waiting for the directory server or memcached? Actually neither, it means waiting for a response from the web server (technically it's making an RPC call via HTTP Ajax). The RPC call needs to go through the web server, memcached, and typically will invoke one or more directory server queries, and run a bunch of Python to massage everything before the RPC returns with the result. It doesn't look like you've got much difference in times between with pagination on and pagination off. I don't know the pagination code but I suspect it's run after the RPC call returns so the RPC timing is not telling us much with respect to that. Waiting for up to 3 seconds for an RPC call does seem on the high side. Do you have a lot of LDAP data? But really, unless we get timing results for each component we're grasping at straws :-( Here's a portion of the initial load of the Users page: json/ipa/session POST 200 Success application/json jquery.js:7365 Script 33.94KB 33.10KB 1.57s 1.47s 96ms (1.37s waiting) json/ipa/session POST 200 Success application/json jquery.js:7365 Script 568.09KB 564.36KB 3.92s 2.95s 963ms (2.85s waiting) json/ipa/session POST 200 Success application/json jquery.js:7365 Script 556.94KB 553.40KB 3.78s 2.94s 836ms (2.83s waiting) json/ipa/session POST 200 Success application/json jquery.js:7365 Script 46.93KB 46.38KB 1.87s 1.71s (1.60s waiting) Now, with the pagination turned back on: json/ipa/session POST 200 Success application/json jquery.js:7365 Script 33.94KB 33.10KB 1.58s 1.48s 100ms (1.38s waiting) json/ipa/session POST 200 Success application/json jquery.js:7365 Script 568.09KB 564.36KB 4.05s 3.09s 964ms (2.98s waiting) json/ipa/session POST 200 Success application/json jquery.js:7365 Script 556.94KB 553.40KB 3.84s 2.99s 855ms (2.88s waiting) json/ipa/session POST 200 Success application/json jquery.js:7365 Script 46.93KB 46.38KB 1.52s 1.51s (1.40s waiting) Steve ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] 2.20 dirsrv memory usage
Rob may have already contacted you with this, but if not we would like to get more debugging information by have the server log what is occurring when it processes your requests. To do this you'll need to turn on the debug flag in the IPA configuration file /etc/ipa/default.conf, add a line that says: debug = True Then restart the server to pick up the new configuration. The information will be written to /var/log/httpd/error_log. We only need the contents of the log from when the server was restarted with debug logging enabled. For privacy reasons I suggest you send the contents of the log to one of the IPA team members directly in a private email, not to the public freeipa list. Thanks! John -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] unable to logout of IPA
On 07/27/2012 02:06 AM, Dan Scott wrote: Hi, I'm not sure if this is relevant, but Firefox preserves session cookies across browser restarts. This was discussed on the Security Now! podcast recently: http://www.grc.com/sn/sn-360.htm Search for 'sessionstore' and read a little before and after. Are session cookies relevant for kerberos authentication? It's only tangentially relevant. IPA does use session cookies. IPA logout destroys the session on the server making the session cookie stored in the browser invalid. However, SSO (Single Sign-On) continues to work as it's supposed to. As long as you have valid credentials in your kerberos cache you'll be automatically logged in (albeit with a brand new session and session cookie). All this is by design. You can logout of IPA which destroys your session, but unless you also destroy your credentials the automatic SSO process will be applied the next time you visit the web UI. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] whats the recommended way to change OU structures in IPA?
On 08/06/2012 11:07 AM, Dale Macartney wrote: Although I can use any ldapmodify capable tool to do this, I was wondering what the "recommended" way that we should be telling customers who want to change OU trees? e.g, say in a high school using IPA, they wished to create a parent OU called cn=school accounts,dc=example,dc=com and inside that OU there are two more OU's. One for staff and one for students? Presumably this is not possible through the webUI. Also what are the implications if I move a user that was created with "ipa user-add" into a non-default OU? will it break anything? Whats the best way to move an existing user into one of the above OU's? IPA only supports flat name spaces, you cannot partition the default containers. This was an early IPA design decision. If you use ldapmodify to move entries it will break your IPA installation. You can however assign users, hosts, etc. to groups. Then use group membership to control how a particular group of users behaves. It's easy to automate group membership via automember. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users