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] 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] 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] 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] 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] 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] 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/instance/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] 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] 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 jden...@redhat.com 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 jden...@redhat.com 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 jden...@redhat.com 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 SNIPPED OUT THE KEY STRING ... send: ?xml version='1.0' encoding='UTF-8'? \nmethodCall\nmethodNameping/methodName\nparams\n/params\n/methodCall\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 jden...@redhat.com 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 jden...@redhat.com 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 pvikt...@redhat.com 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 jden...@redhat.com 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 jden...@redhat.com 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 pvikt...@redhat.com 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 jden...@redhat.com 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 jden...@redhat.com 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 jden...@redhat.com 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 jden...@redhat.com 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 jden...@redhat.com 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 jden...@redhat.com 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 jden...@redhat.com 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 jden...@redhat.com 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 jden...@redhat.com 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 jden...@redhat.com 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 jden...@redhat.com 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 jden...@redhat.com 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 jden...@redhat.com 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 jden...@redhat.com 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 jden...@redhat.com 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 jden...@redhat.com 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 jden...@redhat.com 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 jden...@redhat.com 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 jden...@redhat.com 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 jden...@redhat.com 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 jden...@redhat.com 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 jden...@redhat.com 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 jden...@redhat.com 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 jden...@redhat.com 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 jden...@redhat.com 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 jden...@redhat.com: 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 jden...@redhat.com 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 mko...@redhat.com: 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 jden...@redhat.com 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 jden...@redhat.com
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 jden...@redhat.com
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] testing AD trust on Fedora 18
On 12/19/2012 05:50 AM, Sumit Bose wrote: On Wed, Dec 19, 2012 at 09:13:21AM +0100, Petr Spacek wrote: On 12/18/2012 09:56 PM, John Dennis wrote: ipa: ERROR: unable to parse cookie header 'ipa_session=f963e8e4006fdcd79e1a2a5a989b4d01; Domain=IPA.DOMAIN; Path=/ipa; Expires=Thu, 18 Dec 2012 13:54:33 GMT; Secure; HttpOnly': unable to parse expires datetime 'Thu, 18 Dec 2012 13:54:33' John, could it be related to LANG environment variable? Is the parser sensitive to LANG/other variables? Andre, could you post output from echo $LANG, please? (Logged in as user which ran IPA commands.) Petr, I think you are right, I can reproduce this issue if httpd and the client session use incompatible LANG settings. E.g. I have LANG=C for httpd and LANG=de_DE.UTF-8 in the shell. Thank you for confirming this. I too wondered if this might be the case. I recall wondering if the locale would be an issue when using using strptime() to parse the date. I'll file a ticket and provide a patch. -- John Dennis jden...@redhat.com 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] testing AD trust on Fedora 18
On 12/19/2012 01:10 PM, Andre Rodrigues wrote: Thank you all for the answers.. I noticed that I had installed freeipa with incorrect parameters, so I reinstalled freeipa and I think now default.conf is correct. answering some questions: On 12/18/2012, John Dennis wrote: Please provide the contents of /etc/ipa/default.conf. [root@mtest ~]# more /etc/ipa/default.conf [global] host=mtest.unicamp.br basedn=dc=ipa,dc=unicamp,dc=br realm=IPA.UNICAMP.BR domain=ipa.unicamp.br xmlrpc_uri=https://mtest.unicamp.br/ipa/xml ldap_uri=ldapi://%2fvar%2frun%2fslapd-IPA-CCUEC-UNICAMP-BR.socket enable_ra=True mode=production Do you have a .ipa/default.conf file set? If so that overrides the values in /etc/ipa/default.conf. If you have that as well please provide that as well. No On 12/19/2012, Petr Spacek wrote: John, could it be related to LANG environment variable? Is the parser sensitive to LANG/other variables? Andre, could you post output from echo $LANG, please? (Logged in as user which ran IPA commands.) -- Petr^2 Spacek yes it could be... [root@mtest ~]# echo $LANG pt_BR.UTF-8 Thank you, this is a bug in the cookie handling that only shows up with non-English locales. We already have a patch for it. https://fedorahosted.org/freeipa/ticket/3313 On 12/19/2012, Sumit Bose wrote: Andre, as a workaround until the packages are fixed please call yum install m2crypto service httpd restart HTH Thanks Sumit! The error with ad-trust package is not returned to me. Now it seems that the problem is with the DNS settings of AD domain: ipa: ERROR: Unable to resolve domain controller for 'adtest.unicamp.br' domain. Additional instructions: IPA manages DNS, please verify your DNS configuration and make sure that service records of the 'adtest.unicamp.br' domain can be resolved. Examples how to configure DNS with CLI commands or the Web UI can be found in the documentation. but I think I will solve it quickly. -- John Dennis jden...@redhat.com 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] testing AD trust on Fedora 18
On 12/18/2012 01:26 PM, Andre Rodrigues wrote: Hi all, I'm testing AD trust following this how to: http://www.freeipa.org/page/IPAv3_testing_AD_trust but when I set ipa dnszone-add I get this: [root@m ~] ipa dnszone-add AD.DOMAIN --name-server=AD.NAME http://AD.NAME --admin-email=MY.EMAIL --force --forwarder=AD.IP –forward-policy=only ipa: ERROR: unable to parse cookie header 'ipa_session=f963e8e4006fdcd79e1a2a5a989b4d01; Domain=IPA.DOMAIN; Path=/ipa; Expires=Thu, 18 Dec 2012 13:54:33 GMT; Secure; HttpOnly': unable to parse expires datetime 'Thu, 18 Dec 2012 13:54:33' This is an error message from something I wrote. I can't explain why it can't parse the expires cookie attribute because using the value cited in the error message it parses just fine. The only thing I can think of is that the time module was not imported in cookie.py, but in my copy of the file it is imported. However one thing I did immediately notice, the cookie has Domain=IPA.DOMAIN, that's not valid, it's supposed to be a FQDN. What is the value of xmlrpc_uri in your /etc/ipa/default.conf? and when I set ipa trust-add I get the following error: [root@m ~] ipa trust-add --type=ad AD.DOMAIN --admin Adminstrator --password Active directory domain administrator's password: ipa: ERROR: unable to parse cookie header 'ipa_session=7d6aeb2c92ff3197a9d3c04421f6ba15; Domain=IPA.DOMAIN; Path=/ipa; Expires=Tue, 18 Dec 2012 18:32:05 GMT; Secure; HttpOnly': unable to parse expires datetime 'Tue, 18 Dec 2012 18:32:05' Sorry, someone else will have to help you with the below: ipa: ERROR: Cannot perform join operation without Samba 4 support installed. Make sure you have installed server-trust-ad sub-package of IPA but I have the server-trust-ad installed:-- John Dennis jden...@redhat.com 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] testing AD trust on Fedora 18
On 12/18/2012 03:30 PM, Sumit Bose wrote: On Tue, Dec 18, 2012 at 03:16:47PM -0500, John Dennis wrote: On 12/18/2012 01:26 PM, Andre Rodrigues wrote: Hi all, I'm testing AD trust following this how to: http://www.freeipa.org/page/IPAv3_testing_AD_trust but when I set ipa dnszone-add I get this: [root@m ~] ipa dnszone-add AD.DOMAIN --name-server=AD.NAME http://AD.NAME --admin-email=MY.EMAIL --force --forwarder=AD.IP –forward-policy=only ipa: ERROR: unable to parse cookie header 'ipa_session=f963e8e4006fdcd79e1a2a5a989b4d01; Domain=IPA.DOMAIN; Path=/ipa; Expires=Thu, 18 Dec 2012 13:54:33 GMT; Secure; HttpOnly': unable to parse expires datetime 'Thu, 18 Dec 2012 13:54:33' This is an error message from something I wrote. I can't explain why it can't parse the expires cookie attribute because using the value cited in the error message it parses just fine. The only thing I can think of is that the time module was not imported in cookie.py, but in my copy of the file it is imported. However one thing I did immediately notice, the cookie has Domain=IPA.DOMAIN, that's not valid, it's supposed to be a FQDN. What is the value of xmlrpc_uri in your /etc/ipa/default.conf? and when I set ipa trust-add I get the following error: [root@m ~] ipa trust-add --type=ad AD.DOMAIN --admin Adminstrator --password Active directory domain administrator's password: ipa: ERROR: unable to parse cookie header 'ipa_session=7d6aeb2c92ff3197a9d3c04421f6ba15; Domain=IPA.DOMAIN; Path=/ipa; Expires=Tue, 18 Dec 2012 18:32:05 GMT; Secure; HttpOnly': unable to parse expires datetime 'Tue, 18 Dec 2012 18:32:05' Sorry, someone else will have to help you with the below: I guess this error message is just triggered by the cookie error. In theory no, the inability to process a cookie should do nothing other than log the fact, everything else should proceed as normal (without cookies you just get slower performance, but it should continue to work). However, the values in the cookie show something is very wrong with the configuration. Please provide the contents of /etc/ipa/default.conf. Do you have a .ipa/default.conf file set? If so that overrides the values in /etc/ipa/default.conf. If you have that as well please provide that as well. Adding verbose debugging information will help. Add the -d option to the ipa command to turn on debug level information and capture the output. Those messages will help us diagnose the problem. bye, Sumit ipa: ERROR: Cannot perform join operation without Samba 4 support installed. Make sure you have installed server-trust-ad sub-package of IPA but I have the server-trust-ad installed:-- -- John Dennis jden...@redhat.com 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] adding group fails with Type or value exists
On 11/15/2012 04:21 PM, Qing Chang wrote: Adding group produces error message Type or value exists and fails. As shown below, I tried a few different group name to ensure that there is no duplicates: [root@ipa1 ~]# ipa -d group-add example --desc=Test ipa: DEBUG: Caught fault 4203 from server http://ipa1/ipa/xml: Type or value exists: ipa: DEBUG: Destroyed connection context.xmlclient ipa: ERROR: Type or value exists: Saw in a thread in March, it did not appear there was a resolution. Hello Qing: What version of ipa are you using? Which distribution (e.g. F17, RHEL 6.3)? -- John Dennis jden...@redhat.com 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] Failed installation
On 10/17/2012 12:40 PM, Bret Wortman wrote: I recently tried installing freeipa on a new server, but ipa-server-install had problems around this point: Configuring certificate server: Estimated time 3 minutes 30 seconds [1/18]: creating certificate server user [2/18]: creating pki-ca instance [3/18]: configuring certificate server instance ipa : CRITICAL failed to configure ca instance Command '/usr/bin/perl /usr/bin/pkisilent ConfigureCA -cs_hostname fs1.wedgeofli.me http://fs1.wedgeofli.me -cs_port 9445 -client_certdb_dir /tmp/tmp-UvBMbL -client_certdb_pwd -preop_pin HHxKHUz5RRfzQ3OkFMlR -domain_name IPA -admin_user admin -admin_email root@localhost -admin_ -agent_name ipa-ca-agent -agent_key_size 2048 -agent_key_type rsa -agent_cert_subject CN=ipa-ca-agent,O=WEDGEOFLI.ME http://WEDGEOFLI.ME -ldap_host fs1.wedgeofli.me http://fs1.wedgeofli.me -ldap_port 7389 -bind_dn cn=Directory Manager -bind_ -base_dn o=ipaca -db_name ipaca -key_size 2048 -key_type rsa -key_algorithm SHA256withRSA -save_p12 true -backup_pwd -subsystem_name pki-cad -token_name internal -ca_subsystem_cert_subject_name CN=CA Subsystem,O=WEDGEOFLI.ME http://WEDGEOFLI.ME -ca_ocsp_cert_subject_name CN=OCSP Subsystem,O=WEDGEOFLI.ME http://WEDGEOFLI.ME -ca_server_cert_subject_name CN=fs1.wedgeofli.me http://fs1.wedgeofli.me,O=WEDGEOFLI.ME http://WEDGEOFLI.ME -ca_audit_signing_cert_subject_name CN=CA Audit,O=WEDGEOFLI.ME http://WEDGEOFLI.ME -ca_sign_cert_subject_name CN=Certificate Authority,O=WEDGEOFLI.ME http://WEDGEOFLI.ME -external false -clone false' returned non-zero exit status 255 Unexpected error - see ipaserver-install.log for details: Configuration of CA failed [root@fs1 ~]# The logfile revealed the following stack trace: # Attempting to connect to: fs1.wedgeofli.me:9445 http://fs1.wedgeofli.me:9445 Exception in LoginPanel(): java.lang.NullPointerException ERROR: ConfigureCA: LoginPanel() failure ERROR: unable to create CA ### 2012-10-17T16:24:53Z DEBUG stderr=Exception: Unable to Send Request:java.net.ConnectException: Connection refused java.net.ConnectException: Connection refused at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:339) at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:200) at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:182) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:391) at java.net.Socket.connect(Socket.java:579) at java.net.Socket.connect(Socket.java:528) at java.net.Socket.init(Socket.java:425) at java.net.Socket.init(Socket.java:241) at HTTPClient.sslConnect(HTTPClient.java:326) at ConfigureCA.LoginPanel(ConfigureCA.java:244) at ConfigureCA.ConfigureCAInstance(ConfigureCA.java:1157) at ConfigureCA.main(ConfigureCA.java:1672) java.lang.NullPointerException at ConfigureCA.LoginPanel(ConfigureCA.java:245) at ConfigureCA.ConfigureCAInstance(ConfigureCA.java:1157) at ConfigureCA.main(ConfigureCA.java:1672) Now I seem to be stuck. I tried uninstalling the freeipa-server package with # yum remove freeipa-server and then reinstalled it the same way, but ipa-server-install won't run no matter what I attempt. Any thoughts? I'm pretty new to IPA. There is a good chance this is due to a version mismatch between the IPA packages and the dogtag packages. You didn't mention which OS you're using nor the versions of the relevant packages, that would have been helpful. In any event I would make sure all your packages are up to date. -- John Dennis jden...@redhat.com 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 host-del
On 09/05/2012 10:46 AM, Ade Lee wrote: The logs seem to show that the CA cannot find JSS. What versions of the following are on your system? pki-ca, pki-common, jss, nss, tomcat6, tomcat, java Is this a system that was working and now fails to work? Or is this a new instance? Let's verify the link to the jss4.jar is in place. Note this is an x86_64 system, Mathew did make some adjustments to where native (i.e. arch specific) jars are located. I think it moved from /usr/lib/java to /usr/lib64/java. pki-create would have been modified to set up links to them on a new install but it's possible the links weren't updated on an existing install. Not sure, guessing at the moment but I think it's worth pursuing. Please do this, it will list all the jars which should be visible to the CA tomcat instance, the jss4.jar should have a link under /var/lib/pki-ca/common/lib. sudo ls -l /var/lib/pki-ca/common/lib /var/lib/pki-ca/webapps/ca/WEB-INF/lib We want to verify none of the symbolic links listed above are dangling (point to a non-existent file). Pay particular attention to /var/lib/pki-ca/common/lib/jss4.jar, does it point to an existing file that's a valid jar? If not can you locate jss4.jar? Is it now under /var/lib64/java? If so adjust the symbolic link under /var/lib/pki-ca/common/lib to point to it. Do thinks work now after restarting? John -- John Dennis jden...@redhat.com 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 host-del
On 09/05/2012 02:40 PM, george he wrote: Thanks a lot. It's deleted now! The .jar thing (i.e. jss4.jar, osutil.jar, and symkey.jar) was pointing to /usr/lib/..., but when I was struggling, I read on the web there was a post saying they should point to /usr/lib64/..., so I changed them. The weird thing is I THINK they were pointing to existing files, but now they are not. So I changed the links one more times to make them pointing to /usr/lib/..., restarted ipa, and host-del worked. Thanks again, guys. George Glad it's working. Obviously we would like to know how you got into this situation and perhaps open a bug. But unfortunately since you've manually changed links it's hard to know if the logic used to update an existing system is robust or not. I recall when the issue of where to locate native jars on 64bit came up there was a fair amount of back and forth over where things would be installed and which links to introduce. Unfortunately I do not recall the final resolution, it might be that the tomcat instances were supposed to continue to point to /usr/lib/java and links would be set up there to point to the 64bit version. In any event I don't think we can file a bug at this point, but perhaps we need to pay attention and see if anyone else gets bitten by this. John *From:* John Dennis jden...@redhat.com *To:* a...@redhat.com *Cc:* george he george_...@yahoo.com; freeipa-users@redhat.com freeipa-users@redhat.com *Sent:* Wednesday, September 5, 2012 2:04 PM *Subject:* Re: [Freeipa-users] ipa host-del On 09/05/2012 10:46 AM, Ade Lee wrote: The logs seem to show that the CA cannot find JSS. What versions of the following are on your system? pki-ca, pki-common, jss, nss, tomcat6, tomcat, java Is this a system that was working and now fails to work? Or is this a new instance? Let's verify the link to the jss4.jar is in place. Note this is an x86_64 system, Mathew did make some adjustments to where native (i.e. arch specific) jars are located. I think it moved from /usr/lib/java to /usr/lib64/java. pki-create would have been modified to set up links to them on a new install but it's possible the links weren't updated on an existing install. Not sure, guessing at the moment but I think it's worth pursuing. Please do this, it will list all the jars which should be visible to the CA tomcat instance, the jss4.jar should have a link under /var/lib/pki-ca/common/lib. sudo ls -l /var/lib/pki-ca/common/lib /var/lib/pki-ca/webapps/ca/WEB-INF/lib We want to verify none of the symbolic links listed above are dangling (point to a non-existent file). Pay particular attention to /var/lib/pki-ca/common/lib/jss4.jar, does it point to an existing file that's a valid jar? If not can you locate jss4.jar? Is it now under /var/lib64/java? If so adjust the symbolic link under /var/lib/pki-ca/common/lib to point to it. Do thinks work now after restarting? John -- John Dennis jden...@redhat.com mailto:jden...@redhat.com Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -- John Dennis jden...@redhat.com 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 host-del
On 09/03/2012 06:00 PM, george he wrote: Hello all, I'm trying to reinstall myipaclient so I did ipa-client-install --uninstall on my client, but when I try to do ipa host-del on the sever, I got the following error: ipa: ERROR: Certificate operation cannot be completed: Unable to communicate with CMS (Not Found) What does it mean, and how do I fix this? ps, both the server and the client are centos 6.3 I'm guessing the configuration option that specifies where to locate your CA was lost. Check and see if ca_host is defined in any of the .conf files under /etc/ipa, if so is it the correct host? If not then the server will assume it's co-located on the same machine. Is your CA on the same machine as your IPA server? One other thing to check, is the CA running? Do an ipactl status to verify or an ipactl restart. -- John Dennis jden...@redhat.com 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 host-del
On 09/04/2012 08:28 AM, george he wrote: There's only one conf file in /etc/ipa/, which is default.conf. ca_host is not defined there. But I think my CA is the IPA server. Everything is reported running: # ipactl status Directory Service: RUNNING KDC Service: RUNNING KPASSWD Service: RUNNING MEMCACHE Service: RUNNING HTTP Service: RUNNING CA Service: RUNNING but when I try # ipactl restart, it reports: Starting httpd: [Tue Sep 04 08:19:10 2012] [warn] worker ajp://localhost:9447/ already used by another worker [Tue Sep 04 08:19:10 2012] [warn] worker ajp://localhost:9447/ already used by another worker ajp worker threads are used by tomcat instances of which the CA is one example. It sounds like your CA has gotten into a funny state. I would do a ipactl stop to shut down all your services and then do a ps to look for any Java processes that are still running (I'm assuming the only Java you're running on this box would be for the CA). If you can identify a running Java process that you believe belongs to the CA then kill it and try starting IPA again (or you could use a big hammer and reboot). BTW, the ajp threads are the listeners on the CA communication ports, if those treads are not in the right state you could see the CA communication problems you reported. If that still does not work then my next suggestion would be to add this line to /etc/ipa/default.conf debug=True and restart IPA, that will cause verbose logging to be written to /var/log/httpd/error_log which may have more detailed messages indicating where things might be going wrong. -- John Dennis jden...@redhat.com 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 host-del
On 09/04/2012 10:23 AM, george he wrote: First of all, i don't see any java process after ipactl stop. Then I turned on debug and this is what I get on terminal: # ipa host-del hnl09.psych.yale.edu .. ipa: DEBUG: approved_usage = SSLServer intended_usage = SSLServer ipa: DEBUG: cert valid True for CN=cushing.psych.yale.edu,O=PSYCH.YALE.EDU ipa: DEBUG: handshake complete, peer = 130.132.167.68:443 ipa: DEBUG: Caught fault 4301 from server http://cushing.psych.yale.edu/ipa/xml: Certificate operation cannot be completed: Unable to communicate with CMS (Service Temporarily Unavailable) ipa: DEBUG: Destroyed connection context.xmlclient ipa: ERROR: Certificate operation cannot be completed: Unable to communicate with CMS (Service Temporarily Unavailable) So there's a fault 4301 being caught. And this is at the end of /var/log/httpd/error_log: [Tue Sep 04 10:17:05 2012] [error] ipa: DEBUG: approved_usage = SSLServer intended_usage = SSLServer [Tue Sep 04 10:17:05 2012] [error] ipa: DEBUG: cert valid True for CN=cushing.psych.yale.edu,O=PSYCH.YALE.EDU [Tue Sep 04 10:17:05 2012] [error] ipa: DEBUG: handshake complete, peer = 130.132.167.68:443 [Tue Sep 04 10:17:05 2012] [error] (111)Connection refused: proxy: AJP: attempt to connect to 127.0.0.1:9447 (localhost) failed [Tue Sep 04 10:17:05 2012] [error] ap_proxy_connect_backend disabling worker for (localhost) [Tue Sep 04 10:17:05 2012] [error] proxy: AJP: failed to make connection to backend: localhost [Tue Sep 04 10:17:05 2012] [error] ipa: INFO: ad...@psych.yale.edu: host_del((u'hnl09.psych.yale.edu',), updatedns=False): CertificateOperationError [Tue Sep 04 10:17:05 2012] [error] ipa: DEBUG: response: CertificateOperationError: Certificate operation cannot be completed: Unable to communicate with CMS (Service Temporarily Unavailable) [Tue Sep 04 10:17:05 2012] [error] ipa: DEBUG: Destroyed connection context.ldap2 Thanks, George It appears as if your CA instance is not running (pki-ca). Depending on which OS you're running on could you verify pki-ca is running via either the service or systemctl command. Do you see any errors in the log files found under /var/log/pki-ca? -- John Dennis jden...@redhat.com 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] KISS: DHCP from IPA
Thanks for the contribution Chris! Just as an aside if you know Python you can call the IPA commands directly and use Python to extract and reformat the data, it might be a lot simpler than doing the bash/awk dance. -- John Dennis jden...@redhat.com 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 over the Internet - Security Implications
On 08/16/2012 09:14 PM, Michael Mercier wrote: Hello, I was wondering what the security implications would be setting up a server to be a freeipa client at one site, and have it join a freeipa system over the internet at another site. ipaclient (siteA) -- internet -- ipaserver (siteB) Is there an IPA document that describes this situation? I'm not aware of any such document but IPA was designed to be secure in multiple ways including traffic on open networks. All network traffic that is sensitive is tunneled in some fashion, usually either by the kerberos protocol or the SSL/TLS protocols. IPA also makes sure strong encryption is utilized for those tunnels. Strong authentication is also required at the endpoints of those tunnels. It really wouldn't make much sense to design an authentication and security manager that itself wasn't secure :-) -- John Dennis jden...@redhat.com 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 jden...@redhat.com 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 jden...@redhat.com 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 pvobo...@redhat.com 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 jden...@redhat.com 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 jden...@redhat.com 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 jden...@redhat.com 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 jden...@redhat.com 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 jden...@redhat.com 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 jden...@redhat.com 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 jden...@redhat.com Looking to carve out IT costs? www.redhat.com/carveoutcosts/ attachment: login1.jpgattachment: login2.jpg___ 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 jden...@redhat.com 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 jden...@redhat.com 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 module
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 jden...@redhat.com
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 jden...@redhat.com 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 jden...@redhat.com 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 jden...@redhat.com 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 jden...@redhat.com 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 jden...@redhat.com 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 jden...@redhat.com 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 jden...@redhat.com 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 jden...@redhat.com 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 Crittendenrcrit...@redhat.com 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 jden...@redhat.com
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 jden...@redhat.com 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 jden...@redhat.com 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 jden...@redhat.com 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 jden...@redhat.com 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 jden...@redhat.com 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] 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 jden...@redhat.com 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 jden...@redhat.com 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 Pald...@redhat.com mailto: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 jden...@redhat.com 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 jden...@redhat.com 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 Dennisjden...@redhat.com 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 Dennisjden...@redhat.com 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 jden...@redhat.com 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 jden...@redhat.com 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 jden...@redhat.com 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 jden...@redhat.com 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 jden...@redhat.com 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 jden...@redhat.com 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
