Re: [Freeipa-users] Unable to communicate with CMS (Service Unavailable)
On Thu, Nov 12, 2015 at 08:55:25PM +0100, Martin Kosek wrote: > On 11/12/2015 04:51 PM, Terry John wrote: > > > >I got a core dump of certmonger failing user abrt but it's huge. Is there > >any particular part that would be useful. > > CCing Nalin and David for the core dump. More below. My initial guess is that it's the same as the one reported in bug #1260871. There's a fix for a problem that might be the cause in 0.77.6 and 0.78.5. If you can try a 0.77.6 build from the COPR system [1], it'll help us figure out if we've correctly identified the cause, or if the problem you're running into is a different one. Thanks, Nalin [1] https://copr.fedoraproject.org/coprs/nalin/certmonger/build/139854/ -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] approving certs?
On Tue, Aug 04, 2015 at 07:29:13AM -0700, Janelle wrote: Hello, Well, I am more used to working with openssl directly, so I am a little confused when using FreeIPA and certmonger. I assume that when a certificate is in this state: status: NEWLY_ADDED_NEED_KEYINFO_READ_PIN stuck: yes That it needs to be approved, but I am not sure where that is. I see all the cert commands, but don't see anything relating to approvals? Am I missing something obvious here? That state means that certmonger went to use the private key (most often for generating a signing request), but couldn't, either because the PIN it was given can't be used to decrypt the private key, or because it's having trouble reading the file in which it's been told the PIN is kept. If there's a PIN file (the -p flag), check the SELinux labeling of the file. Otherwise, check that the value that's specified (with the -P flag) is correct -- if there isn't one, then there should be. HTH, Nalin -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] certmonger + dogtag, bad parsing of returned certificate
On Tue, May 19, 2015 at 12:34:47PM +0200, marcin kowalski wrote: Hi, all. I am trying to integrate certmonger with dogtag instance, and so far i've stumbled on one odd problem. Hopefully this is the right list. I've generated some random cert with getcert request, it has communicated with dogtag, and i approved it there. However, when certmonger retrieves it, it cannot save it to disk ( NEED_TO_NOTIFY_ISSUED_SAVE_FAILED ) Upon inspection of certmonger's request file (in /var/lib/certmonger/requests ), it turns out that there is an extra empty line before end certificate marker line. There is no such line when looking at the cert in dogtag web interface. Is there some method/hook i could use to post process such request files to fix them up? There's no hook for doing that with the data files themselves, because they're meant to be internal details of the implementation, but the data coming back from the enrollment helper, which is what's malformed to begin with, can be corrected at the point when the helper is run. Essentially, you'd replace the configured call to dogtag-submit with a script or other program that checked $CERTMONGER_OPERATION for the values SUBMIT and POLL, ran the dogtag-submit helper, filtered its output to fix this mistake, and returned the helper's exit status to keep things in line with the daemon's expectations. Though, if you're running something older than 0.77, please give 0.77.4 (currently in testing for Fedora 20 and 21) or a development snapshot (from the ipa-devel repo) a try. The 0.77 release had a lot of its parsing reworked as part of adding support for SCEP reply formats, which I think fixed this. The development snapshots add more authentication options to the generic Dogtag helper which you may also want, depending on the enrollment profile you're using. HTH, Nalin -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Certificate renewal issues for dogtag GUI (9443/9444/9445 ports)
On Mon, May 11, 2015 at 05:14:16PM +0200, Thibaut Pouzet wrote: There is one that remains expired, despite all the efforts I put into renewing it. This is the one used for the pki-ca administration pages reachable on ports 9443, 9444 and 9445. Here is its status after trying to resubmit it : getcert resubmit -i 20150511145941 -K HTTP/ipa_server getcert list -i 20150511145941 Number of certificates and requests being tracked: 9. Request ID '20150511145941': status: CA_UNREACHABLE ca-error: Server at https://ipa_server/ipa/xml failed request, will retry: 4301 (RPC failed at server. Certificate operation cannot be completed: FAILURE (Invalid Request)). stuck: no key pair storage: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='Server-Cert cert-pki-ca',token='NSS Certificate DB',pin='1234' certificate: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='Server-Cert cert-pki-ca',token='NSS Certificate DB' CA: IPA issuer: CN=Certificate Authority,O=ipa_domain subject: CN=ipa_server,O=ipa_domain expires: 2015-04-09 04:58:33 UTC key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth pre-save command: post-save command: track: yes auto-renew: yes The request settings you've got there don't quite look like the settings for the certificate I have in the same place on my system. The CA we use for that one is usually 'dogtag-ipa-renew-agent', and since it's a CA-specific certificate (i.e., internal to Dogtag) rather than a full-blown IPA-managed service, I wouldn't expect it to have a Kerberos principal name associated with it. Can you try getcert resubmit -d /var/lib/pki-ca/alias -n 'Server-Cert cert-pki-ca' -c dogtag-ipa-renew-agent -K to change both the CA which is used, and to remove the principal name from the signing request? My IPA server (the same version of both it and Dogtag that you're running) didn't complain when I tried it the way you're doing it, so if the invalid token exception is being caused by something else, then this might not help. But we can at least rule these things out. One other thing I would check is if the PIN that certmonger has for the certificate's private key matches the value listed for internal (not internaldb) in /var/lib/pki-ca/conf/password.conf, and that supplying that value when certutil -K -d /var/lib/pki-ca/alias asks for one allows the database to be decrypted so that its contents can be listed. If they don't agree, or certutil fails to list the database's contents, then one or both of them is incorrect about the database's password. HTH, Nalin -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Certificate renewal issues for dogtag GUI (9443/9444/9445 ports)
On Tue, May 12, 2015 at 06:39:13PM +0200, Thibaut Pouzet wrote: After doing what you recommended, the CSR have changed in the debug log : Certificate Request: Data: Version: 0 (0x0) Subject: O=ipa_domain, CN=ipa_server Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (2048 bit) Modulus: 00:b8:d6:d3:51:c0:4c:ce:2a:c1:1b:b7:60:a3:6a: 04:ec:6d:75:94:c4:b9:b5:4a:40:3a:be:d5:12:d8: 77:af:a2:8e:a4:5a:47:cf:3b:4d:7a:8a:13:2b:1a: 93:c0:f3:a5:ae:25:44:86:56:72:d9:73:9e:e3:22: 0e:7c:66:64:87:f7:b1:06:2f:c5:ca:7d:b6:3f:9e: 67:9e:b3:5b:72:56:bd:12:e6:65:65:8b:b3:5a:5d: 53:94:a2:d7:be:53:97:59:9d:c4:2e:1a:79:b5:c2: d1:ac:85:90:04:0b:1b:c6:27:fb:82:46:88:c1:31: 38:83:1d:a8:83:bc:a3:a9:fa:3e:de:91:e0:84:d6: 00:cb:e1:80:38:61:55:4c:60:6b:d7:55:7c:5d:88: f6:c2:bf:42:57:3b:82:30:2b:29:b9:84:93:90:60: c6:1a:f4:3a:45:fa:04:69:60:c0:86:33:02:4d:69: 04:07:e0:37:36:b2:2f:ae:6d:28:5a:86:90:65:30: b3:9b:5f:e4:8d:f2:d1:dd:1b:6a:02:23:fb:07:7e: 0d:e0:f0:64:1a:34:8c:2d:f5:db:63:22:82:6f:e4: 53:72:c1:dc:9a:e9:37:4c:f0:3b:39:d4:31:d6:b9: 62:c4:93:2d:30:47:f4:4a:2f:76:fc:08:f4:82:28: 1b:fb Exponent: 65537 (0x10001) Attributes: a0:00 Signature Algorithm: sha256WithRSAEncryption 10:ef:cf:ff:6c:63:72:61:c3:b5:5e:8e:b0:20:f0:63:13:43: bb:3b:63:c8:4e:6f:34:63:33:cc:47:af:8a:dc:2d:13:2a:58: 87:7c:d7:5e:e9:b3:e7:f4:47:b7:7b:eb:77:0b:7c:0e:58:20: dd:62:a8:a0:8b:31:1e:54:f0:dd:3f:44:4a:e7:a2:a6:64:85: 9f:10:0e:06:75:33:94:82:f3:8f:89:66:e1:7f:65:21:85:b8: 69:6d:e7:35:a5:a7:08:1d:51:55:48:13:b8:e3:2d:6f:99:c1: ce:1e:81:e3:fb:93:3a:f0:86:0d:43:96:31:93:fb:87:fb:53: 46:02:e1:dd:05:55:85:72:35:fa:72:6d:c6:35:d4:6d:9e:be: db:ee:e6:8c:7b:b1:5a:cd:4d:cc:8e:3e:10:4e:a7:d3:61:36: ae:86:59:df:51:a3:0f:38:79:b8:e0:bd:eb:25:44:a4:43:b0: 93:7f:1e:43:aa:d5:30:d3:e3:a0:bd:ee:08:b7:88:9a:cd:a0: 8c:ac:2a:8f:71:ec:64:70:72:91:f8:d2:e8:55:5b:22:1f:2e: 60:6c:a4:be:ee:42:09:a6:71:25:ec:37:43:a1:e6:15:63:8f: 05:97:61:1d:8e:25:5d:76:df:8b:66:7f:85:27:8b:93:98:a9: 3e:cc:cb:d8 There is no more this weird friendlyName :unable to print attribute thing, but the NoSuchTokenException is still in the debug log of pki-ca Thank you for you answer though, we've still made some progress in identifying that I messed the CA used for this certificate ! Hmm, so what you've got there looks pretty normal for a renewal request. Just to rule out a problem with the request's signature or the encoding of the subject name in the request (the latter is a bug in versions of certmonger before 0.72), can you check the version of the certmonger package and show us the base64-encoded form of the signing request? I'm just about grasping at straws here, but the NoSuchTokenException exception appears to be coming from the jss library, and is thrown when it can't find the software module that is used for accessing the server's keys. Can you verify that your /etc/pki-ca/CS.cfg file contains these lines? jss.configDir=/var/lib/pki-ca/alias/ jss.enable=true jss.secmodName=secmod.db Is there a ca.requestVerify.token value set in /etc/pki-ca/CS.cfg? I don't have one. The Dogtag logic looks like it would try to use one set there rather than the default, but letting it use the default looks like the intended way of doing things. Which version of the jss and tomcatjss packages are installed? I'm using jss-4.2.6-24.el6 and tomcatjss-2.1.0-3.el6 here. If none of this turns up anything, then I'm going to have to defer to the Dogtag team, too. Nalin -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] ipa-getcert Problem ?
On Wed, Apr 15, 2015 at 08:47:12AM +0200, Günther J. Niederwimmer wrote: Thank you for the answer and help I mean this is working now ;) after some --uninstall and delete the certificate (?) . The wrong command I found with google :-(. The status command is not working on my system! The status command's only job is to set an exit status to indicate whether or not a certificate's okay (0 means okay, other values are described in the man page), which is why it needs to be told which certificate it's being asked about. If you're looking for something human readable, you probably wanted to use list. If it's not working as expected in some other way, could you describe the problem you're seeing in more detail? HTH, Nalin -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] ipa-getcert Problem ?
On Tue, Apr 14, 2015 at 08:18:38PM +0200, Günther J. Niederwimmer wrote: Hello I mean I have a Problem with the ipa-getcert script. system CentOS 7 (1503) and IPA 4.1.x can any help or declare my mistake or is this a IPA Problem I do a kinit admin ipa-getcert request -d /etc/pki/nssdb -n Server-Cert -K HOST/xxx.4gjn.prv -N 'CN=xxx.4gjn.prv,O=$4GJN.PRV' and have afterward with ipa-getcert list Number of certificates and requests being tracked: 1. Request ID '20150414172251': status: CA_REJECTED ca-error: Server at https://ipa.4gjn.prv/ipa/xml denied our request, giving up: 2100 (RPC failed at server. Insufficient access: Insufficient 'add' privilege to add the entry 'krbprincipalname=HOST/xxx.4gjn@4gjn.prv,cn=services,cn=accounts,dc=4gjn,dc=prv'.). stuck: yes key pair storage: type=NSSDB,location='/etc/pki/nssdb',nickname='Server-Cert',token='NSS Certificate DB' certificate: type=NSSDB,location='/etc/pki/nssdb',nickname='Server- Cert' CA: IPA issuer: subject: expires: unknown pre-save command: post-save command: track: yes auto-renew: yes The server rejected the request because no service with the Kerberos principal name in the request exists yet. The host service is the one that's automatically created, and because Kerberos principal names are case sensitive, HOST is seen as being different from host. The certmonger service uses the local host's credentials in /etc/krb5.keytab to authenticate when it sends the request to the CA (so you could skip the kinit step above), and the host doesn't have the necessary privileges to create a new service, and that's why that particular error message is coming back from the server. ipa-getcert status process 4731: arguments to dbus_message_new_method_call() were incorrect, assertion path != NULL failed in file dbus-message.c line 1262. This is normally a bug in some application using the D-Bus library. D-Bus not built with -rdynamic so unable to print a backtrace Abgebrochen (Speicherabzug geschrieben) That's a bug in ipa-getcert. It should be producing an error message, suggesting that you'd need to specify additional options to indicate which request you wanted to check the status on, like so: getcert status -i 20150414172251 getcert status -d /etc/pki/nssdb -n Server-Cert I suggest 'ipa-getcert resubmit -i 20150414172251 -K host/xxx.4gjn.prv' (note the lower case) to change the parameters in the certificate request, which should be enough to satisfy the server's requirements. HTH, Nalin -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] IPA web interface always giving Your session has expired. Please re-login.
On Wed, Apr 01, 2015 at 07:45:10PM +0300, Ben .T.George wrote: HI yes i have creared cache. tried from different browsers, tried from portable browser, configure kerbros plugin in firefox this is what i got from inspect: http://s9.postimg.org/51c5809xr/kerb.jpg Just to be sure, the policies for ticket lifetimes are still set to their defaults, right? Is there anything in the server-side logs (/var/log/krb5kdc.log, /var/log/httpd/error_log) that might shed some light on things, perhaps after having set debug=True in the [global] section of the server's /etc/ipa/default.conf and restarted the httpd service? Nalin -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Openvpn and Certificates
On Wed, Apr 01, 2015 at 07:02:56PM +0200, Andrew Holway wrote: I understand from previous discussions that client certificates are not yet supported in FreeIPA, instead I understand one can use service certificates. From an OpenVPN standpoint I'm guessing this is fine because a vpn client can be entered in Freeipa as a client and a certificate generated for it. This might actually be a preferred model for VPN. My OVPN server config looks like this: ca ca.crt cert server.crt key server.key # Diffie hellman parameters. dh dh2048.pem I guess I can use the ipa-getcert request -f /path/to/server.crt -k /path/to/private.key -r command to generate the server.crt and private.key and I know where to find ca.crt however: Unless there are other requirements on the contents of the certificate, I'd expect that to work. I see mention in the docs of optionally requiring that a peer certificate include a particular value in its nsCertType extension (support for that's not currently planned AFAIK), or a particular value in its extendedKeyUsage (EKU) extension (there's a ticket [1] for supporting that), but you're not setting such a requirement above. - How about the Diffie hellman parameters? - Is dh2048.pem just a bunch of shared primes that enable the two parties to establish encryption together? Yes to both. I'm going by the PKI section of the howto [2] and the man page here. - Is it bad If this file is compromised? The howto and man pages say it's not required to be kept secret, and the secrecy of a key that's generated using DH key agreement doesn't depend on the parameters being kept secret, so I'd say no. HTH, Nalin [1] https://fedorahosted.org/freeipa/ticket/2915 [2] https://openvpn.net/index.php/open-source/documentation/howto.html#pki -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Problems with ssh and install-uninstall-install sequence on the server
On Wed, Mar 18, 2015 at 05:55:52PM -0400, Rob Crittenden wrote: getcert status process 31282: arguments to dbus_message_new_method_call() were incorrect, assertion path != NULL failed in file dbus-message.c line 1262. This is normally a bug in some application using the D-Bus library. D-Bus not built with -rdynamic so unable to print a backtrace Aborted (core dumped) Please open a bug against certmonger. I'm pretty sure this one's already being tracked as #1148001. Cheers, Nalin -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] certmonger question
On Tue, Nov 11, 2014 at 08:48:18AM +0100, Natxo Asenjo wrote: 2014-11-11 08:34:33 [11677] Certificate Local Signing Authority valid for 31473668s. 2014-11-11 08:34:33 [11677] Running result is 1481416576. 2014-11-11 08:34:33 [11677] Final result is 1481416576. Okay, that's weird. The result being tallied here is the earliest of the not-valid-after times for the CA's certificate, but on my development box, those numbers are coming back scaled up by a factor of a million. That suggests that the logic that determines how long to wait before trying to fetch new data is somehow arriving at a much lower value than it should, which would explain why it immediately polls for a new local signer certificate. Since you mention that this seems to be specific to 32-bit boxes, I think I need to switch to that one to try to sort out what's happening here, since I'm on a 64-bit box. [snip] # CACert, ipa, etc, domain.tld dn: cn=CACert,cn=ipa,cn=etc,dc=domain,dc=tld cACertificate;binary:: TUlJRG5EQ0NBb1NnQXdJQkFnSUJBVEFOQmdrcWhraUc5dzBCQVFzRkF EQTdNUmt3RndZRFZRUUtFeEJWVGtsWUxrbFNTVk5hVDFKSExrNU1NUjR3SEFZRFZRUURFeFZEWlhK MGFXWnBZMkYwWlNCQmRYUm9iM0pwZEhrd0hoY05NVEl4TVRBM01qRXlOREUxV2hjTk1qQXhNVEEzT WpFeU5ERTFXakE3TVJrd0Z3WURWUVFLRXhCVlRrbFlMa2xTU1ZOYVQxSkhMazVNTVI0d0hBWURWUV FERXhWRFpYSjBhV1pwWTJGMFpTQkJkWFJvYjNKcGRIa3dnZ0VpTUEwR0NTcUdTSWIzRFFFQkFRVUF BNElCRHdBd2dnRUtBb0lCQVFDeTJXVnk3UWtIaXVFTlcvemtNZUQ0SUxvcU9ydXVZS3ZiMitycWV1 STlpdyt6QkJ0NTY5WFN4cmdjeWVUcTBHNjNSamJYZ3JBem90NEVoWWc2TW9lcERWQ24wQm51clVmZ 2JDZjVSMEVib2lnamJvaDVNR25QeWxIZWZMUkdBUk5VQ3djVEdBNHVSOVpRTC9yRVVxV2t0bVpqYW 5ZRXZPUDhVQmV1cTVXUDVlbWFYOFUwM1N6TUErY1FUOXcvengwZUFPWWdaVzV5eDNhQTVRNEZ1OHF XcU1HR0FPQTZ5RFFXcW1JcGd4aUZISFJhN2hRSzRBamVIZ3ZhQ29sYVU5NzlMaDVqQXYvWHdyWXRv azFHK1VWRXA0NUlOcGZ4cjVkTGUwM29nblBGUFowL3h3YkJxdHQvMnFuNnJrNEw0dWtINFA5ZzRSd zBvN1UxeUpWeC9TT0pBZ01CQUFHamdhb3dnYWN3SHdZRFZSMGpCQmd3Rm9BVW81ZmtpaTY0eno3cU 0vSzhrOVlqM3FtRU5tZ3dEd1lEVlIwVEFRSC9CQVV3QXdFQi96QU9CZ05WSFE4QkFmOEVCQU1DQWN Zd0hRWURWUjBPQkJZRUZLT1g1SW91dU04KzZqUHl2SlBXSTk2cGhEWm9NRVFHQ0NzR0FRVUZCd0VC QkRnd05qQTBCZ2dyQmdFRkJRY3dBWVlvYUhSMGNEb3ZMMnRrWXpBeExuVnVhWGd1YVhKcGMzcHZjb WN1Ym13Nk9EQXZZMkV2YjJOemNEQU5CZ2txaGtpRzl3MEJBUXNGQUFPQ0FRRUFKMjhnZG96ZC9wdE 9NNVBUS0t3eVYrb3RPL3drM3lFcnNseHBOVWhSWmdTTlV3VCt0NnRmRi9qK2pKUlY1c1grankwOWM 5RG8rcDNIeTlnUm5JVkpPTkRTY3ZNVjluRGM3NUM2SkdYVStGZE5KSitEYnBlcC9Sc1FqSHJaK3Vu d0l5QVdvT3BCb2w4c0d6TjV0WGJlby9NNm1HRnhhQlRIMUdLdGd2NENLYnpRQW90dk1hR3h6S2pTY 0hSc0dhZXJOU0NacC85MHlSSnlwQzNNT29zVUZjRmw0Q29ZSEI0MlhEVHpqdnpaUWNhRk5jZ1lYT2 NpdWp3d1lITnpzU3FZY0lLRlNXdVd2TisrN2c0eXhRTWx1OFFXME1zL1BudG1UbU8yY0RkTkkxdHV qVnlCS2U1OTl5NE8vRXMvTUJHdER0VkE4NUFMa3NKT1UyN2JqdHZiQmc9PQ== # search result search: 4 result: 0 Success Yup. If you trim the whitespace and run that through 'base64 -d', you'll see base64-encoded data. If you run _that_ through 'base64 -d', you'll get the certificate, which confirms that it was double-encoded, as I think Martin noted. [snip] So there is something wrong but how come I only see this in this client after upgrading it to centos 6.6? Not specifically. Caching the root certificate (for the IPA and local signers, anyway), is new functionality that was added for other users. HTH, Nalin -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] certmonger question
On Tue, Nov 11, 2014 at 11:13:12AM -0500, Nalin Dahyabhai wrote: Since you mention that this seems to be specific to 32-bit boxes, I think I need to switch to that one to try to sort out what's happening here, since I'm on a 64-bit box. Okay, found it, and as 64-bit cleanliness sometimes is, it's a one-line change. The nightlies should have it starting with anything claiming to be 0.76.7 or later. If you can open this in bugzilla, it'll probably look less weird to parts of management than if I did it. Thanks, Nalin -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] certmonger question
On Mon, Nov 10, 2014 at 04:17:49PM +0100, Natxo Asenjo wrote:
Nov 10 15:51:31 apachetest03 certmonger: Decoding error on
TUlJRG5EQ0NBb1NnQXdJQkFnSUJBVEFOQmdrcWhraUc5dzBCQVFzRkFEQTdNUmt3#012RndZRFZRUUtFeEJWVGtsWUxrbFNTVk5hVDFKSExrNU1NUjR3SEFZRFZRUURFeFZE#012WlhKMGFXWnBZMkYwWlNCQmRYUm9iM0pwZEhrd0hoY05NVEl4TVRBM01qRXlOREUx#012V2hjTk1qQXhNVEEzTWpFeU5ERTFXakE3TVJrd0Z3WURWUVFLRXhCVlRrbFlMa2xT#012U1ZOYVQxSkhMazVNTVI0d0hBWURWUVFERXhWRFpYSjBhV1pwWTJGMFpTQkJkWFJv#012YjNKcGRIa3dnZ0VpTUEwR0NTcUdTSWIzRFFFQkFRVUFBNElCRHdBd2dnRUtBb0lC#012QVFDeTJXVnk3UWtIaXVFTlcvemtNZUQ0SUxvcU9ydXVZS3ZiMitycWV1STlpdyt6#012QkJ0NTY5WFN4cmdjeWVUcTBHNjNSamJYZ3JBem90NEVoWWc2TW9lcERWQ24wQm51#012clVmZ2JDZjVSMEVib2lnamJvaDVNR25QeWxIZWZMUkdBUk5VQ3djVEdBNHVSOVpR#012TC9yRVVxV2t0bVpqYW5ZRXZPUDhVQmV1cTVXUDVlbWFYOFUwM1N6TUErY1FUOXcv#012engwZUFPWWdaVzV5eDNhQTVRNEZ1OHFXcU1HR0FPQTZ5RFFXcW1JcGd4aUZISFJh#012N2hRSzRBamVIZ3ZhQ29sYVU5NzlMaDVqQXYvWHdyWXRvazFHK1VWRXA0NUlOcGZ4#012cjVkTGUwM29nblBGUFowL3h3YkJxdHQvMnFuNnJrNEw0dWtINFA5ZzRSdzBvN1Ux#012eUpWeC9TT0pBZ01CQUFHamdhb3dnYWN3SHdZRFZSMGpCQmd3Rm9BVW81ZmtpaTY0#012eno3cU0vSzhrOVlqM3FtRU5tZ3dEd1lEVl!
Iw!
VEFRSC9CQVV3QXdFQi96QU9CZ05W#012SFE4QkFmOEVCQU1DQWNZd0hRWURWUjBPQkJZRUZLT1g1SW91dU04KzZqUHl2SlBX#012STk2cGhEWm9NRVFHQ0NzR0FRVUZCd0VCQkRnd05qQTBCZ2dyQmdFRkJRY3dBWVlv#012YUhSMGNEb3ZMMnRrWXpBeExuVnVhWGd1YVhKcGMzcHZjbWN1Ym13Nk9EQXZZMkV2#012YjJOemNEQU5CZ2txaGtpRzl3MEJBUXNGQUFPQ0FRRUFKMjhnZG96ZC9wdE9NNVBU#012S0t3eVYrb3RPL3drM3lFcnNseHBOVWhSWmdTTlV3VCt0NnRmRi9qK2pKUlY1c1gr#012ankwOWM5RG8rcDNIeTlnUm5JVkpPTkRTY3ZNVjluRGM3NUM2SkdYVStGZE5KSitE#012YnBlcC9Sc1FqSHJaK3Vud0l5QVdvT3BCb2w4c0d6TjV0WGJlby9NNm1HRnhhQlRI#012MUdLdGd2NENLYnpRQW90dk1hR3h6S2pTY0hSc0dhZXJOU0NacC85MHlSSnlwQzNN#012T29zVUZjRmw0Q29ZSEI0MlhEVHpqdnpaUWNhRk5jZ1lYT2NpdWp3d1lITnpzU3FZ#012Y0lLRlNXdVd2TisrN2c0eXhRTWx1OFFXME1zL1BudG1UbU8yY0RkTkkxdHVqVnlC#012S2U1OTl5NE8vRXMvTUJHdER0VkE4NUFMa3NKT1UyN2JqdHZiQmc9PQ==#012
(1240 bytes)!
The certmonger service keeps stopping (nothing logged), I notice when running:
$ sudo getcert list
Please verify that the certmonger service has been started.
This I got right after restarting it and getting a right result, with
about 5 minutes in between. Now it's done i again:
]$ sudo getcert list
Number of certificates and requests being tracked: 1.
Request ID '20140410142412':
status: MONITORING
stuck: no
key pair storage:
type=NSSDB,location='/etc/pki/nssdb',nickname='IPA Machine Certificate
- apachetest03.domain.tld',token='NSS Certificate DB'
certificate: type=NSSDB,location='/etc/pki/nssdb',nickname='IPA
Machine Certificate - apachetest03.domain.tld',token='NSS Certificate
DB'
CA: IPA
issuer: CN=Certificate Authority,O=DOMAIN.TLD
subject: CN=apachetest03.domain.tld,O=DOMAIN.TLD
expires: 2016-04-10 14:24:15 UTC
key usage:
digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
eku: id-kp-serverAuth,id-kp-clientAuth
pre-save command:
post-save command:
track: yes
auto-renew: yes
]$ sudo getcert list
Please verify that the certmonger service has been started.
How can I debug this?
First thing would be to run the daemon with additional logging - I
usually use '-d3' to watch what's going on while the daemon's running
various tasks.
The data logged with the Decoding Error looks like a certificate that's
been base64-encoded, and then base64-encoded again, which is very odd,
since that error message is logged in cases where it fails to parse a
root certificate that it has just retrieved from the CA, and that data
shouldn't have been mangled like that.
Can you check the contents of the caCertificate attribute in the
cn=cacert,cn=ipa,cn=etc entry under the IPA base DN in the directory
server, and perhaps provide them? They can be retrieved using a command
like:
ldapsearch -b cn=cacert,cn=ipa,cn=etc,$SUFFIX -s base -Y GSSAPI caCertificate
The attribute values are supposed to be certificates in binary form,
which ldapsearch will likely base64-encode for display -- ldapsearch
will indicate that it's doing this by separating the attribute name from
the value using two colons ('::') instead of the usual one (':') in its
output, in accordance with ldif(5).
HTH,
Nalin
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] 3.3.3 - Unable to install remote client
On Wed, Sep 24, 2014 at 01:02:34PM -0600, ToBeReplaced wrote:
In details below, the domain name, server host name, and ip address has
been changed.
The server is sitting behind a router with ip 12.34.56.78. The server
was configured with `--enable-dns` and `192.168.1.100 ipa.example.com
ipa` in /etc/hosts.
firewalld has been set to open up ports for ldap, ldaps, kerberos,
kpasswd, dns, ntp, http, https on both the client and server. Port 7389
is also open on the server.
The router has been configured to forward all of the above ports through
12.34.56.78 to 192.168.1.100.
The client is sitting on a different network (say, behind a router with
ip 98.76.54.32).
Its /etc/hosts includes `12.34.56.78 ipa.example.com ipa`.
Its /etc/resolv.conf includes `nameserver 12.34.56.78`
ipa-client-install fails with:
Discovery was successful!
Hostname: laptop-1.example.com
Realm: EXAMPLE.COM
DNS Domain: example.com
IPA Server: ipa.example.com
BaseDN: dc=example,dc=com
Synchronizing time with KDC...
Successfully retrieved CA cert
Subject: CN=Certificate Authority,O=EXAMPLE.COM
Issuer: CN=Certificate Authority,O=EXAMPLE.COM
Valid From: Wed Sep 24 17:44:28 2014 UTC
Valid Until: Sun Sep 24 17:44:28 2034 UTC
Enrolled in IPA realm EXAMPLE.COM
Created /etc/ipa/default.conf
New SSSD config will be created
Configured /etc/sssd/sssd.conf
Configured /etc/krb5.conf for IPA realm EXAMPLE.COM
trying https://ipa.example.com/ipa/xml
Forwarding 'ping' to server 'https://ipa.example.com/ipa/xml'
Cannot connect to the server due to Kerberos error: Kerberos
error: ('Unspecified GSS failure. Minor code may provide more
information', 851968)/(Cannot contact any KDC for realm
'EXAMPLE.COM', -1765328228). Trying with delegate=True
trying https://ipa.example.com/ipa/xml
Forwarding 'ping' to server 'https://ipa.example.com/ipa/xml'
Second connect with delegate=True also failed: Kerberos error:
('Unspecified GSS failure. Minor code may provide more
information', 851968)/(Cannot contact any KDC for realm
'EXAMPLE.COM', -1765328228)
Cannot connect to the IPA server XML-RPC interface: Kerberos
error: ('Unspecified GSS failure. Minor code may provide more
information', 851968)/(Cannot contact any KDC for realm
'EXAMPLE.COM', -1765328228)
Installation failed. Rolling back changes.
Unenrolling client from IPA server
Unenrolling host failed: Error obtaining initial credentials:
Cannot contact any KDC for requested realm.
Removing Kerberos service principals from /etc/krb5.keytab
Disabling client Kerberos and LDAP configurations
Redundant SSSD configuration file /etc/sssd/sssd.conf was moved
to /etc/sssd/sssd.conf.deleted
Restoring client configuration files
nscd daemon is not installed, skip configuration
nslcd daemon is not installed, skip configuration
Client uninstall complete.
`cat /var/log/ipaclient-install.log | grep ERROR -C 25 -m 1`
2014-09-24T18:11:49Z INFO Configured /etc/krb5.conf for IPA
realm EXAMPLE.COM
2014-09-24T18:11:49Z DEBUG Starting external process
2014-09-24T18:11:49Z DEBUG args=keyctl search @s user
ipa_session_cookie:host/laptop-1.example@example.com
2014-09-24T18:11:49Z DEBUG Process finished, return code=1
2014-09-24T18:11:49Z DEBUG stdout=
2014-09-24T18:11:49Z DEBUG stderr=keyctl_search: Required key
not available
2014-09-24T18:11:49Z DEBUG Starting external process
2014-09-24T18:11:49Z DEBUG args=keyctl search @s user
ipa_session_cookie:host/laptop-1.example@example.com
2014-09-24T18:11:49Z DEBUG Process finished, return code=1
2014-09-24T18:11:49Z DEBUG stdout=
2014-09-24T18:11:49Z DEBUG stderr=keyctl_search: Required key
not available
2014-09-24T18:11:49Z DEBUG failed to find session_cookie in
persistent storage for principal
'host/laptop-1.example@example.com'
2014-09-24T18:11:49Z INFO trying https://ipa.example.com/ipa/xml
2014-09-24T18:11:49Z DEBUG Created connection context.xmlclient
2014-09-24T18:11:49Z DEBUG Try RPC connection
2014-09-24T18:11:49Z INFO Forwarding 'ping' to server
'https://ipa.example.com/ipa/xml'
2014-09-24T18:12:07Z DEBUG Destroyed connection
context.xmlclient
2014-09-24T18:12:07Z INFO Cannot connect to the server due to
Kerberos error: Kerberos error: ('Unspecified GSS failure.
Minor code may provide more information', 851968)/(Cannot
Re: [Freeipa-users] Certificate system unavailable
On Mon, Jan 13, 2014 at 04:07:16PM +0100, Sigbjorn Lie wrote: After I restarted dirsrv, pki-cad and then the httpd on ipa01 the status of the request is now: Request ID '20120119194518': status: CA_UNREACHABLE ca-error: Server failed request, will retry: 907 (RPC failed at server. cannot connect to 'https://ipa01.dns.domain:443/ca/agent/ca/displayBySerial': [Errno -12269] (SSL_ERROR_EXPIRED_CERT_ALERT) SSL peer rejected your certificate as expired.). stuck: yes key pair storage: type=NSSDB,location='/etc/dirsrv/slapd-DNS-DOMAIN',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/dirsrv/slapd-DNS-DOMAIN//pwdfile.txt' certificate: type=NSSDB,location='/etc/dirsrv/slapd-DNS-DOMAIN',nickname='Server-Cert',token='NSS Certificate DB' CA: IPA issuer: CN=Certificate Authority,O=DNS-DOMAIN subject: CN=ipa01.dns.domain,O=DNS-DOMAIN expires: 2014-01-19 19:45:18 UTC eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: track: yes auto-renew: yes However I cannot find the certificate that's expired? That error message was the one the IPA server received and then relayed back to certmonger, so I'd expect that the expired certificate is the agent certificate that IPA uses when connecting to the CA's agent interface. That's stored in the NSS database in /etc/httpd/alias, with nickname ipaCert. HTH, Nalin ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] EXTERNAL: Re: NIS Compat issues
On Tue, Jan 07, 2014 at 05:22:22AM -0500, Joseph, Matthew (EXP) wrote: When I run ypcat on the IPA servers it states that ypbind can't communicate. I started ypbind on the secondary IPA server so now I can run ypcat. Is running ypbind on the IPA servers necessary? According to all of the documentation I read it doesn't mention anything about ypbind on the servers. Any system on which you intend to run ypcat, ypmatch, or any of the NIS client commands should run ypbind, whether it's talking to a more traditional NIS server or an IPA server with its NIS service enabled. HTH, Nalin ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] EXTERNAL: Re: NIS Compat issues
On Tue, Jan 07, 2014 at 10:35:58AM -0500, Rob Crittenden wrote: Nalin Dahyabhai wrote: Any system on which you intend to run ypcat, ypmatch, or any of the NIS client commands should run ypbind, whether it's talking to a more traditional NIS server or an IPA server with its NIS service enabled. I run ypcat w/o ypbind all the time for testing. You just need to specify the server and domain on the command-line: $ ypcat -h `hostname` -d example.com passwd I left that tidbit out, but yeah, I often use it that way as well when troubleshooting. On that topic, 'rpcinfo -p' is handy for checking that the NIS server is properly registered with its local port mapper (as a ypserv server), which is necessary for ypbind to find it. Cheers, Nalin ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Startup issue witrh dirsrv using slapi-nis
On Thu, Oct 03, 2013 at 05:02:44PM -0400, Dmitri Pal wrote: On 09/27/2013 08:13 AM, Ade wrote: I have a dirsrv server using the slapi-nis plugin to provide 190+ nis maps. It works well apart from one issue - boot up If I do a reboot, the dirsrv starts up ok, but slapi-nis doesnt seem to register to rpc - logging in and restarting dirsrv fixes it I tried disabling dirsrv and putting a start into rc.local - exactly the same I tried disabling dirsrv and putting a start into rc.local with a sleep 120 first, and this works !! So it seems like it needs something to startup and settle first - any ideas? I can see that rpcbind starts before dirsrv. I even wrote a small script that waits for rpcinfo -p to return non zero before continuing to start dirsrv - didnt work Did anyone reply? Not on the list, but given the sender, I think he found me elsewhere, and we debugged it. Was the problem solved? Yes, it should be fixed in slapi-nis 0.50. That version reconnects to rpcbind if rpcbind has dropped the connection from the plugin since the plugin last connected to rpcbind (the plugin connects first before the server drops privileges, then after the server drops privileges, it computes the contents of map entries, and it only sends the registration request to rpcbind once it's ready to answer client queries). It turns out some RPC libraries (which rpcbind links with) will disconnect clients which they consider to be idle after some period, and that was biting us because computing map contents was taking more than that length of time, in part because the search filter that was used to select entries for use in populating NIS maps was referring to attributes that weren't indexed. Nalin ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] slapi-nis user password error
On Thu, Sep 05, 2013 at 09:17:36AM -0500, cbul...@gmail.com wrote:
The users were imported from a openldap server and the password
encryption is MD5.
Is that {CRYPT} using an md5-based crypt, or {MD5} or {SMD5}? A client
that's trying to check passwords using hashes which it reads via NIS is
usually only compatible with hashes that are identified with {CRYPT}.
I installed slapi-nis in the server and configure a NIS client(Red Hat
5.9) with FreeIPA server (Red Hat 6.3, FreeIPA: 3.0.0-26).
I'm able to get info of the users from NIS client (getent passwd
user_id) but when the user try to log in to the NIS client the
authentication fails.
Which authentication mechanism did you configure in combination with NIS
for user information?
Slapi-nis was installed and configured using the default options.
Any clue about this problem or How can I debug this?
If you're using pam_unix (which you probably are, if you're using
neither LDAP nor Kerberos for authenticating users), then you need to
have {CRYPT} hashes in your user entries. If you don't have those,
you'll need to remedy that first, by configuring the server to use the
CRYPT password storage scheme (IIRC the default is SSHA), and then
forcing some password changes. After that, the default configuration
for the version of slapi-nis you have should cause them to start showing
up when you use getent (or ypmatch) to read the user's entry from the
passwd map.
Then you can double-check that a password is correct by taking a hashed
value and a candidate password and running them through something like
python -c 'import crypt; print crypt.crypt(password,hash)'
to check if hashing the password using the salt that's part of the
hashed value reproduces the hashed value, which is more or less what
pam_unix does to check the password.
That all said, I'd recommend using SSSD's support for reading identity
information via LDAP, or better still its IPA provider, which can
interact with the IPA server when it's in migration mode, and start
moving you toward being able to switch over to using Kerberos.
HTH,
Nalin
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Automount cross-location support
On Sun, May 26, 2013 at 09:40:03PM +0200, Sigbjorn Lie wrote: I did some testing on this. I added an entry to cn=Schema Compatibility, cn=plugins, cn=config, and defined the various settings for the compat plugin. It worked as a charm, the requested automountmaps we're mirrored. However, one glitch when I attempt to actually use it. Setting schema-compat-container-group to cn=default hides all the existing keys in automount location default. Setting it to a level below the cn=default, and the automounter does not see the entries with the error below. It seem like the automounter can only handle a single level of a tree, and does not search subtrees. get_query_dn: lookup(ldap): failed to find query dn under search base dns Were there any messages preceding that one? I'm looking at the sources and there are a couple of code paths that would get to the point where that message is logged, and I only ever see the plugin searching using scope subtree, so I can't be sure what's causing it to not find the new entries. I don't think the flatten trees does any harm, it's already flat, as long as the container-group could be set to cn=default,cn=automount. However it would require logic within the IPA framework to follow any automountinformation=-fstype=autofs auto_anothermapname and also create setup for the additional auto_anothermapname in the compat plugin. And again the idea seem flawed when the additional maps cannot sit under the same schema-compat-container-group. Is there any way to have several entries in the schema compatibility plugin to share the same level of schema-compat-container-group? Not without at least some changes to its internals, I'm afraid. It's basically reusing the same internal representation that's used for NIS maps and NIS domains, and the one-configuration-entry-per-map relationship is what triggers the module's housekeeping when a config entry is added or removed. But I think it could be done. HTH, Nalin ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Expired certs not auto renewed by Cermonger
On Thu, May 02, 2013 at 10:59:11AM -0500, Toasted Penguin wrote: Running FreeIPA 2.1.4 and ran into an issue where a Server-Cert did not auto-renew. ipa-getcert list Number of certificates and requests being tracked: 4. [snip] Request ID '20120615190133': status: CA_UNCONFIGURED ca-error: Error setting up ccache for local host service using default keytab. stuck: yes key pair storage: type=NSSDB,location='/etc/pki/nssdb',nickname='Server-Cert',token='NSS Certificate DB' certificate: type=NSSDB,location='/etc/pki/nssdb',nickname='Server-Cert' CA: IPA issuer: subject: expires: unknown track: yes auto-renew: yes That error's not expected. Assuming there aren't any permissions- related problems (due to SELinux policy or regular filesystem permissions) preventing the submission helper from reading the keytab, can you verify that hostname prints ipa01.ctidata.net, and that kinit -k host/ipa01.ctidata.net succeeds? Request ID '20120925200227': status: GENERATING_CSR ca-error: Unable to determine principal name for signing request. stuck: no key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' certificate: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB' CA: IPA issuer: CN=Certificate Authority,O=CTIDATA.NET subject: CN=ipa01.ctidata.net,O=CTIDATA.NET expires: 2013-03-24 19:56:36 UTC eku: id-kp-serverAuth track: yes auto-renew: yes I verified that the IPA keytab is populated: klist -kt /etc/krb5.keytab Keytab name: WRFILE:/etc/krb5.keytab KVNO Timestamp Principal - 2 07/06/11 21:51:43 host/ipa01.ctidata@ctidata.net 2 07/06/11 21:51:43 host/ipa01.ctidata@ctidata.net 2 07/06/11 21:51:43 host/ipa01.ctidata@ctidata.net 2 07/06/11 21:51:43 host/ipa01.ctidata@ctidata.net 2 07/06/11 21:51:43 host/ipa01.ctidata@ctidata.net 2 07/06/11 21:51:43 host/ipa01.ctidata@ctidata.net 4 07/18/12 21:20:41 host/ipa01.ctidata@ctidata.net 4 07/18/12 21:20:41 host/ipa01.ctidata@ctidata.net 4 07/18/12 21:20:41 host/ipa01.ctidata@ctidata.net 4 07/18/12 21:20:41 host/ipa01.ctidata@ctidata.net 5 07/18/12 21:21:00 host/ipa01.ctidata@ctidata.net 5 07/18/12 21:21:00 host/ipa01.ctidata@ctidata.net 5 07/18/12 21:21:00 host/ipa01.ctidata@ctidata.net 5 07/18/12 21:21:00 host/ipa01.ctidata@ctidata.net 6 05/02/13 15:02:10 host/ipa01.ctidata@ctidata.net 6 05/02/13 15:02:10 host/ipa01.ctidata@ctidata.net 6 05/02/13 15:02:10 host/ipa01.ctidata@ctidata.net 6 05/02/13 15:02:10 host/ipa01.ctidata@ctidata.net and ran kvno host/ipa01.ctidata.net to see what the KDC shows for this principle: host/ipa01.ctidata@ctidata.net: kvno = 6 Not sure what caused the ca_errors but I need to at least manually renew the certs and then figure out what went wrong. Any advice on what the ca_errors mean and how I can fix the issue? The Unable to determine principal name for signing request. stems from IPA's certificate submission API's requirement that each certificate request include the associated Kerberos principal name, and certmonger not knowing what value to send. I'm guessing that there wasn't one specified with the -K option when certmonger was told to keep an eye on the certificate, and if there was already a certificate there, a principla name couldn't be read from it. Based on where the certificate's being stored, it's probably intended to be used for the HTTP service on the host, so its principal name would be HTTP/ipa01.ctidata@ctidata.net. If you run: ipa-getcert resubmit -i 20120925200227 \ -K HTTP/ipa01.ctidata@ctidata.net that should provide certmonger with the missing information and get things going again. HTH, Nalin ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Expired certs not auto renewed by Cermonger
On Thu, May 02, 2013 at 11:45:51AM -0500, Toasted Penguin wrote:
Nalin,
Thanks for your response. Running `hostname` does result in
ipa01.ctidata.net and kinit -k host/ipa01.ctidata.net does also succeed.
I ran ` ipa-getcert resubmit -i 20120925200227 -K HTTP/
ipa01.ctidata@ctidata.net`
and it resulted in this:
Request ID '20120615190133':
status: CA_UNCONFIGURED
ca-error: Error setting up ccache for local host service using default
keytab.
stuck: yes
key pair storage:
type=NSSDB,location='/etc/pki/nssdb',nickname='Server-Cert',token='NSS
Certificate DB'
certificate: type=NSSDB,location='/etc/pki/nssdb',nickname='Server-Cert'
CA: IPA
issuer:
subject:
expires: unknown
track: yes
auto-renew: yes
Can you retrieve the contents of the request and save it to a temporary
file, like so:
reqfile=`grep -l '^id=20120615190133' /var/lib/certmonger/requests/*`
awk '/BEGIN .*REQ/,/END .*REQ/ {sub(^( |csr=),);print}' $reqfile \
~/req.csr
And then try to manually submit it to the server for signing, in the way
that certmonger would, like so:
/usr/libexec/certmonger/ipa-submit -P bogus/`hostname` ~/req.csr
Hopefully the error output there will give us more information about
what's going on when the submission helper's failing to set up a ccache.
If it manages to get past that point, I expect it to fail because you
hopefully don't have a principal named bogus defined on the local
host. But at that point we'll have gotten past errors creating the
ccache, and we'll have to find another way to figure out why it failed
here.
As an aside, we provide better information for this error in the
ca-error note with later versions than you appear to have, so tracking
down this information won't always be this complicated.
Request ID '20120925200227':
status: CA_UNREACHABLE
ca-error: Server failed request, will retry: -504 (libcurl failed to
execute the HTTP POST transaction, explaining: Peer certificate cannot be
authenticated with known CA certificates).
stuck: yes
key pair storage:
type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS
Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt'
certificate:
type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS
Certificate DB'
CA: IPA
issuer: CN=Certificate Authority,O=CTIDATA.NET
subject: CN=ipa01.ctidata.net,O=CTIDATA.NET
expires: 2013-03-24 19:56:36 UTC
eku: id-kp-serverAuth
track: yes
auto-renew: yes
There's an error verifying the server's certificate using the local copy
of the CA certificate in /etc/ipa/ca.crt. Is it also expired?
Nalin
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Expired certs not auto renewed by Cermonger
On Thu, May 02, 2013 at 12:45:34PM -0500, Toasted Penguin wrote: Here is the output from the submit: /usr/libexec/certmonger/ipa-submit -P bogus/`hostname` ~/req.csr Submitting request to https://ipa01.ctidata.net/ipa/xml;. Fault -504: (libcurl failed to execute the HTTP POST transaction, explaining: Peer certificate cannot be authenticated with known CA certificates). Server failed request, will retry: -504 (libcurl failed to execute the HTTP POST transaction, explaining: Peer certificate cannot be authenticated with known CA certificates). Regarding /etc/ipa/ca.crt, it isn't expired it shows its valid until July 6, 2019. Hmm, so for both cases, you're seeing errors verifying the IPA server's certificate. Can you double-check the certificates and that the server's looks like it was issued by the CA? This should more or less repeat the part of the process that's giving libcurl trouble, and show us the certificates, too: ipahost=`grep ^host= /etc/ipa/default.conf | cut -f2- -d=` openssl s_client -CAfile /etc/ipa/ca.crt \ -connect $ipahost:https -showcerts /dev/null Nalin ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Expired certs not auto renewed by Cermonger
On Thu, May 02, 2013 at 01:23:04PM -0500, Toasted Penguin wrote: /etc/ipa/ca.crt was issued by O=CTIDATA.NET, CN=Certificate Authority All the certs monitored by Certmonger show the same issuer. Ok, good. (If that hadn't been the case, I wouldn't have had an explanation to offer.) Wasn't getting anything back when running the ipahost script you provided, ran ipahost=`grep ^host= /etc/ipa/default.conf | cut -f2- -d=` and echo $ipahost shows nothing so I just ran the openssl section manually: Hmm. Curious. That might be a leftover from having different releases installed at various times on my test box. Thanks for continuing on. openssl s_client -CAfile /etc/ipa/ca.crt -connect ipa01.ctidata.net:https -showcerts /dev/null Results: CONNECTED(0003) depth=1 O = CTIDATA.NET, CN = Certificate Authority verify return:1 depth=0 O = CTIDATA.NET, CN = ipa01.ctidata.net verify error:num=10:certificate has expired notAfter=Mar 24 19:56:36 2013 GMT verify return:1 depth=0 O = CTIDATA.NET, CN = ipa01.ctidata.net notAfter=Mar 24 19:56:36 2013 GMT verify return:1 --- Certificate chain 0 s:/O=CTIDATA.NET/CN=ipa01.ctidata.net i:/O=CTIDATA.NET/CN=Certificate Authority -BEGIN CERTIFICATE- # -END CERTIFICATE- 1 s:/O=CTIDATA.NET/CN=Certificate Authority i:/O=CTIDATA.NET/CN=Certificate Authority -BEGIN CERTIFICATE- -END CERTIFICATE- --- Server certificate subject=/O=CTIDATA.NET/CN=ipa01.ctidata.net issuer=/O=CTIDATA.NET/CN=Certificate Authority --- No client certificate CA names sent --- SSL handshake has read 1959 bytes and written 463 bytes --- New, TLSv1/SSLv3, Cipher is AES256-SHA Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1 Cipher: AES256-SHA Session-ID: # Session-ID-ctx: Master-Key: Key-Arg : None Krb5 Principal: None PSK identity: None PSK identity hint: None Start Time: 1367518514 Timeout : 300 (sec) Verify return code: 10 (certificate has expired) --- DONE Yup, that's the problem: the IPA server's certificate wasn't able to be replaced while it was still valid, and now it can no longer ask itself for a new one. With 2.1.4, I think the simplest way to sort this is to stop the services (ipactl stop; service certmonger stop), roll the system date back, start the services up again, possibly use 'ipa-getcert resubmit' to force updating (it should happen automatically, but forcing it to happen a second time won't hurt). Then shut things down, set the correct time on the clock, and bring everything back up again. Hopefully there's a smarter way to do it, but I'm blanking on it if there is one. HTH, Nalin ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] IPA - NIS Compatability
On Wed, Mar 27, 2013 at 11:07:44AM -0400, Joseph, Matthew (EXP) wrote: Here is the entry that is in dse.ldif: Dn= nis-domain=domain.ca+nis-map=hosts.byname,CN=NIS Server,cn=plugin,cn=config objectClass: top objectClass: extensibleObject nis-map: hosts.byname nis=base: cn=computers,cn=accounts,dc=domain,dc=ca nis-domain: domain.ca nis-secure: no creatorsName: cn=directory manager modifiersName: cn=directory manager So when I run ypcat hosts it just brings up a blank entry so it is actually seeing that a table should be there. Any ideas? Looks like you've got a typo: nis=base where nis-base was intended. HTH, Nalin ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] EXTERNAL: Re: IPA - NIS Compatability
On Wed, Mar 27, 2013 at 01:42:58PM -0400, Joseph, Matthew (EXP) wrote:
Hey Nalin,
Sorry typo on my part. It does say nis-base.
Alright then. The next thing to check is if the directory entries the
plugin's finding have data that the plugin expects to use to create
entries in the NIS map.
Based on your configuration:
nis-map: hosts.byname
nis=base: cn=computers,cn=accounts,dc=domain,dc=ca
nis-domain: domain.ca
nis-secure: no
And these defaults (courtesy of nisserver-plugin-defs -m hosts.byname):
nis-filter: ((ipHostNumber=*)(cn=*))
nis-keys-format: %{cn}
nis-value-format: %first(%{cn}) %{ipHostNumber} %merge( ,%{cn})
The plugin's looking for host entries which contain one or more of both
the 'cn' and 'ipHostNumber' attributes. Do you have an example entry
from that area of the tree? Does it contain those attributes?
Nalin
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] KPasswd TCP issues
On Tue, Feb 19, 2013 at 10:49:42AM -0700, ninib...@worldd.org wrote: I used IPA from the CentOS 6 repositories and I am having an issue I can't seem to solve. ?I installed a server and a client with no issues, but upon Nessus scans of the server, port 464 kpasswd UDP was flagged for a ping-pong DoS attack. ?With this information I noticed kpasswd also listens on TCP 464 which I understand was used for over-sized requests and other errors. ?I attempted to IPTABLES block UDP for kerberos which resulted in kpasswd no longer functioning from the client. ?Kerberos authentication defaults to TCP without issue, but no matter what i cannot get the client to use TCP for kpasswd. ?Is there a way to force kpasswd on the client to use TCP (i was under the understanding that if UDP failed TCP would be attempted). ?I am running the latest from the CentOS 6 repo's on both server and client. ?Thank you! I just did a spot-check with udp port 464 set to REJECT on my server, with krb5-libs-1.9-33.el6_3.3. It looks like the client is getting an ECONNREFUSED after trying to use the UDP port, and then correctly falling back and opening a TCP connection. Do you have more information about what exactly happens when it fails? What does 'kpasswd' log when it's run with KRB5_TRACE set to /dev/stderr in its environment? Is anything logged to /var/log/kadmind.log on the server when you run 'kpasswd' on the client? Can you try it while using 'tcpdump -s0 -w cap -i any port 464' to capture traffic that's passed between the two? Nalin ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] compat and ou=People
On Mon, Jan 14, 2013 at 12:06:35PM -0700, Orion Poplawski wrote:
We're looking at migrating from 389ds to ipa. Currently our users
are in ou=People with rfc2307 attributes. Is there any way to
provide an ou=people,dc=nwra,dc=com compatibility group in IPA? Or
does everything have to remain under cn=compat? We have a lot of
references to ou=People,dc=nwra,dc=com in clients.
Things show up under cn=compat because the Schema Compatibility plugin
is configured to put them there. With a bit of manual configuration,
the compatibility user entries can show up under ou=People, too. Here's
an initial guess at how that'd look, mostly copy/pasted from the compat
configuration:
dn: ou=people,cn=Schema Compatibility,cn=plugins,cn=config
schema-compat-entry-attribute: objectclass=posixAccount
schema-compat-entry-attribute: gecos=%{cn}
schema-compat-entry-attribute: cn=%{cn}
schema-compat-entry-attribute: uidNumber=%{uidNumber}
schema-compat-entry-attribute: gidNumber=%{gidNumber}
schema-compat-entry-attribute: loginShell=%{loginShell}
schema-compat-entry-attribute: homeDirectory=%{homeDirectory}
ou: people
objectClass: top
objectClass: extensibleObject
schema-compat-search-filter: objectclass=posixAccount
schema-compat-entry-rdn: uid=%{uid}
schema-compat-search-base: cn=users, cn=accounts, dc=nwra,dc=com
schema-compat-container-group: ou=people,dc=nwra,dc=com
You'd need to stop the directory server, add this to its dse.ldif file,
and start it up again.
HTH,
Nalin
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Announcing FreeIPA v3.1.0 Release
On Tue, Dec 11, 2012 at 01:04:37PM -0500, Bret Wortman wrote: This appears to require dirsrv-1.3, which I assume is part of 389-base-devel. I don't see where 1.3 has been made available yet, or am I missing something? Hmm. I'm seeing packages for a 1.3.0-0.1.a1 in Fedora 18, and after a little digging, I find tarballs for it after hitting the Developers page and following the Source link to http://directory.fedoraproject.org/wiki/Source I guess we don't have a final 1.3.0 yet. HTH, Nalin ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] sudo hostgroup sanity check, please?
On Tue, Jul 10, 2012 at 02:15:41PM -0500, KodaK wrote: [snip] My sudo-ldap.conf file: binddn uid=sudo,cn=sysaccounts,cn=etc,dc=validserver,dc=com bindpw validpassword ssl start_tls tls_cacertfile /etc/ipa/ca.crt tls_checkpeer yes bind_timelimit 5 timelimit 15 uri ldap://validserver ldap://validserver2 This may be unrelated, but keep in mind that these should be FQDNs, because that's what the directory server SSL certificates have in them, and a client will check that the name in the certificate the server uses to identify itself matches the name that the client thinks the server has, which the client derives from the URI values given here. sudoers_base ou=SUDOers,dc=unix,dc=magellanhealth,dc=com Assuming your domain name is UNIX.MAGELLANHEALTH.COM and you haven't changed the configuration for the Schema Compatibility plugin, this looks correct. If your domain name is something else, you'll need to change this setting to ou=SUDOers,$basedn, where basedn is the value listed in your server's /etc/ipa/default.conf file. HTH, Nalin ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Serving RFC2307 to OS X clients
On Thu, Jun 07, 2012 at 05:03:11PM -0400, Ian Levesque wrote: Hello, I've read that the schema compatibility plugin should provide a vanilla RFC 2307 view of groups with memberUid attributes. I need this for our OS X clients, which don't seem capable of understanding the RFC 2307bis format of member DNs. So, I enabled the plugin using `ipa-compat-manage enable` and ensured it's loaded via `ipa-compat-manage status`. I restarted the directory server. However, I don't get memberUid attributes. I've seen some docs that say cn=compat should be added to the default base, but that returns nothing: ldapsearch -LLL -x -h sbgrid-directory -b cn=groups,cn=accounts,cn=compat,dc=sbgrid,dc=org cn=builders No such object (32) Matched DN: dc=sbgrid,dc=org Try using cn=groups,cn=compat,dc=sbgrid,dc=org as the search base. We don't put a cn=accounts container under cn=compat by default. HTH, Nalin ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Serving RFC2307 to OS X clients
On Thu, Jun 07, 2012 at 05:44:16PM -0400, Nalin Dahyabhai wrote: The results should look like this: dn: cn=Schema Compatibility,cn=plugins,cn=config nsslapd-pluginEnabled: off Yeah, that second line should be nsslapd-pluginEnabled: on. *facepalm* Nalin ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] insecure IPA'd NFS
On Wed, May 09, 2012 at 09:16:45PM +, Steven Jones wrote: I just setup a RHEL6 server as a NFS server and I have 2 x RHEL6 workstation clients doing NFS via automount as per section 10.3 admin guide 6.3betaall good until I use a Ubuntu client to 'attack it I find the non-IPA's ubuntu client can delete, alter and edit files..kind of OopsI think there is a stage missing in the doc or a bug...can someone have a look at that doc and tell me if a step is missing please? What was the exact command used to mount the filesystem at the client, and what are the contents of the mountpoint's entry in /proc/mounts on the client after it's been mounted? The guide lists sys as one of the security flavors when it shows an example entry in /etc/exports (I guess, because it's demonstrating adding Kerberos settings to a previously-configured export), which I suspect is at least part of it. HTH, Nalin ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Problem: How to download the keytab from IPA without resetting/regenerating a new one??
On Fri, Apr 27, 2012 at 02:52:20PM -0400, Dmitri Pal wrote: I thought that there was a flag for ipa-getkeytab to fetch existing key but my knowledge in this area is rusty. Same with the cert. May be someone else would chime in. There's a way for certificates, at least. If you still have the matching private key on the host (unless I'm mistaken, we don't have optional escrow yet, so if you don't have the private key, you're out of luck, and there's no point in bothering with any of this), you should be able to dig up the corresponding certificate. Since the regular IPA machinery already knows how to pull up a certificate if you know its serial number, we just need to figure out the serial number. On the server, we search Dogtag's directory server instance by running: DOMAIN=EXAMPLE.COM FQDN=clientbox1.example.com ldapsearch -h localhost:7389 -x -D cn=Directory Manager -W \ -b ou=certificateRepository,ou=ca,o=ipaca \ subjectname=cn=$FQDN,o=$DOMAIN cn serialno We'll need to supply the directory server administrator password. We'll get back the cn and serialno values for any matching entries. The cn values appear to be the serial numbers. If multiple certificates were issued to the host, we'll get more than one serial number back. We can pass any of them to ipa cert-show to retrieve the certificate with that was issued with that serial number. The Certificate: value is base64 without a header or footer, but we can pipe the whole value through OpenSSL's utility to both make sure we have the whole thing, and clean it up in the process. Run this command, and copy/paste the value into it: openssl base64 -d | openssl x509 -inform der The result can be stored in the relevant file for use with OpenSSL, or imported into the relevant database for use with NSS. Like Stephen noted about keytabs, though, there should be no harm in just issuing a new certificate for the host in question. Certificates are always issued with limited validity periods, so anything that breaks when if/when a certificate is replaced needs to be fixed anyway. HTH, Nalin ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Screensaver unlock with expired password
On Mon, Apr 16, 2012 at 11:17:35PM +0200, Sigbjorn Lie wrote:
The clients use nss_ldap+pam_krb5, SSSD was crashing for us on RHEL 5.
The server is the IPA server provided in RHEL 6.2.
When I check the logs on the client it states that authentication
succeeded, and that the password has expired. And that's where the
screensaver fails. It show an info message that the password has
expired, and then an error message advising that The password
subsystem has failed...
Best would be if you provide a clear reproduction steps and file a
ticket attaching logs and configuration to it.
If it is a bug in SSSD we would need to fix it ASAP though we have not
seen this behavior in SSSD ever.
This is not SSSD, I believe it either comes down to lack of support
in the KDE screensaver or a requirement for change in the PAM
configuration. The current PAM configuration is set by the
system-config-auth script with the --enable-ldap --enable-krb5
options.
I was hoping for a change in the PAM configuration and that someone
had an example that works to advise me about.
Short version: try turning on the chpw_prompt option for pam_krb5, by
setting something like this in /etc/krb5.conf:
[appdefaults]
pam = {
chpw_prompt = kscreensaver gnome-screensaver
}
Long version: as you've noticed, some applications don't quite do what
PAM expects of them when the user's password has expired. When the user
needs to set a new password, PAM is supposed to succeed in the
authentication phase, and then return an specific status, indicating
that a password change is needed, in the account management phase.
Based on that second result, the application can either start a password
change through PAM (and then allow access only if that change operation
succeeds), or reject the user if it can't handle a password change
(think of FTP servers, where the protocol keeps a server from being able
to ask for a new password). Some applications don't know to do either,
so the password-expired status is treated as a fatal error, and that
appears to be what's going on here.
Turning on the chpw_prompt option causes pam_krb5 to let libkrb5
attempt to change the password, during authentication, if a password
change is needed. Depending on the application, that might be enough to
fix things. It depends on the application to not just reply with the
same password without relaying the question to the user, and you don't
get the chance to add any client-side password quality checking via PAM,
but it might work if the application can handle multiple prompts
correctly.
If that change allows users to log in (or unlock their screens, in this
case), then you've found a bug in the PAM-enabled application, which is
unfortunately not unheard of. The need to provide this option was first
reported [1] after we fixed pam_krb5 to do the right thing [2].
HTH,
Nalin
[1] https://bugzilla.redhat.com/show_bug.cgi?id=509092
[2] https://bugzilla.redhat.com/show_bug.cgi?id=402721
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] (no subject)
On Tue, Mar 20, 2012 at 04:10:19PM -0400, Jimmy wrote: I restarted certmonger and it seems to be working. Is there some way to change the renewal interval so we can simulate this in the lab? I'd like to see it go through a number of renewals to make sure we don't keep having this problem. Attempts to re-enroll are triggered as the not-valid-after date approaches and you cross a threshold time-left value. The default (2419200, 604800, 259200, 172800, 86400, which works out to 28, 7, 3, 2, and 1 day, when you convert from seconds to days) can be modified by setting the ttls value in the [defaults] section of /etc/certmonger/certmonger.conf. To avoid going nuts, the daemon will actually hold off on certificates with a not-before value that's not at least an hour in the past, so adding a really high ttls value (say, longer than the certificate's entire validity period) should force frequent re-enrollments, though I haven't done this myself. HTH, Nalin ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] compat plug-in and replication
On Fri, Mar 16, 2012 at 03:12:03PM -0400, Rob Crittenden wrote: 2. An NIS listener (ipa-nis-manage enable/disable) which requires compat to be enabled. The NIS server plugin shouldn't depend on the compat plugin being enabled. The NIS server depends on being notified of changes to its source data by the server, and because the compat plugin isn't a full-fleged backend database, it doesn't trigger those notifications for the compat entries. HTH, Nalin ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Expired SSL certificate issue with IPA
On Thu, Jan 05, 2012 at 10:38:11AM -0500, Rob Crittenden wrote: My first thought was that there was a CA trust issue. I believe that certmonger uses the NSS database where the certificate is stored so since it is also doing this against Apache (which in theory trust is ok for it to start at all) so I'm baffled. Hopefully the httpd logs will be enlightening. The APIs it's using don't appear to let it do that, so unless there's something going on under the covers, the IPA submission helper trusts only the root certificate found in /etc/ipa/ca.crt. HTH, Nalin ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] NIS maps via FreeIPA
On Tue, Dec 27, 2011 at 09:06:22AM -0500, Boris Epstein wrote: How do I control which NIS maps FreeIPA makes available? Specifically I may need passwd.byname. The the set of maps that the NIS service provides is controlled by the entries listed under the directory server's configuration entry for the plugin (cn=NIS Server, cn=plugins, cn=config), and they're typically named nis-domain=$DOMAIN+nis-map=$MAP. To remove a map (or a whole domain), you can remove the entries, either by stopping the directory server and editing its dse.ldif file directly, or by using the 'ldapdelete' command, like so: ldapdelete -H ldaps://ipa.example.com -D 'cn=Directory Manager' -x \ nis-domain=$DOMAIN+nis-map=$MAP,cn=NIS Server,cn=plugins,cn=config To add a map, you'd create an entry for the map and define how the NIS server plugin will massage the contents of directory server entries to create entries in the map -- there are predefined defaults for a number of maps, so you don't often need to do that, but it's there's more to it than I can fully describe here. The documentation in the slapi-nis package should cover it in depth, though. Also, how do I control what sort of encryption it uses for passwords? I'm assuming you're referring to how user passwords are hashed. The directory server component uses the value of the passwordStorageScheme attribute in the cn=config entry to control how it hashes passwords. The default should be SSHA if it's not set, but I'm guessing you'll want to try CRYPT (without quotes). It won't affect any passwords that have already been set, but it should affect passwords changes made in the future. HTH, Nalin ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] FreeIPA_demonstration_tools CA creation error.
On Thu, Dec 15, 2011 at 09:02:01PM +0100, Ondrej Hamada wrote: On 12/14/2011 06:58 PM, Dmitri Pal wrote: Consistent name resolution is a requirement for IPA. Ondrej, can you please take a closer look and see if this is something with the demo scripts or IPA itself? I don't see a problem in scripts. When the virtual machines are created by ipa-demo, they acquire addresses from dhcp, then - before installation of freeipa - they're configured to use static addresses(the currently assigned ip address is chosen) and also the records are added into /etc/hosts. Do you have an example /etc/hosts that could be double-checked? I wasn't able to reproduce the problem on clean f15 x64, the installation was successful, but few errors like this one appeared: ERROR:root:certmonger failed starting to track certificate: Command '/usr/bin/ipa-getcert start-tracking -d /etc/httpd/alias -n Server-Cert -p /etc/httpd/alias/pwdfile.txt' returned non-zero exit status 1 root: ERRORcertmonger failed starting to track certificate: Command '/usr/bin/ipa-getcert start-tracking -d /etc/httpd/alias -n Server-Cert -p /etc/httpd/alias/pwdfile.txt' returned non-zero exit status 1 Was there anything logged in the the ipaserver-install.log which would indicate why it failed here? Nalin ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] fixing port numbers associated with the NIS
On Mon, Nov 14, 2011 at 05:19:44PM -0500, Boris Epstein wrote: Hello all, I am using the FreeIPA to run NIS via a plugin. Works great - except that the ypserv port numbers end up different after every reboot. That makes it hard to run it with the firewall activated. Does anybody know how to make those port number assignments permanent? There's no tooling specifically for doing this, but the plugin supports it. In order to get it to use a fixed port, you'll need to edit the directory server entry for cn=NIS Server, cn=plugins, cn=config and add a nsslapd-pluginarg0 value which contains the port number you'd like it to use. You can do this either by stopping the directory server, editing its dse.ldif file directly, and then restarting it, or by editing the entry live using ldapmodify and then restarting the server. The latter method (I'm using port 541 here) looks something like this: # ldapmodify -x -D cn=Directory Manager -W - EOF dn: cn=NIS Server,cn=plugins,cn=config changetype: modify replace: nsslapd-pluginarg0 nsslapd-pluginarg0: 541 - EOF # ipactl restart You'll need to supply the Directory Manager password. Once that's done, running rpcinfo -p on the server should show that the NIS service is listening on the desired port. HTH, Nalin ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Change Password problems (Unsupported Version)
On Wed, Sep 28, 2011 at 02:49:02PM +0800, Goff, Raal wrote: The only difference I know about is that the users who CAN change their passwords have not got an expired password (so they can login and use kpasswd from the shell), whereas those who CANNOT change their password need to reset it before logging in (i.e., they get the 'your password has expired, reset it now etc etc). I updated the kerberos libraries/tools on the CentOS 6.0 box using the Continuous Release repository, and then edited the ldap configuration to get around https://bugzilla.redhat.com/show_bug.cgi?format=multipleid=713525 and users can now reset their passwords on that box during login and on the shell (kpasswd). I'm not sure which of these actually fixed the problem (if any). Ah, somehow I'd missed that you were running 6.0. If your client systems are using pam_krb5 instead of SSSD, then you're likely hitting https://bugzilla.redhat.com/show_bug.cgi?id=690583, which was fixed in 6.1. I'll continue to keep an eye on it for now. It may be as you say, a version difference, although I'm unaware of any large differences in versions between the machines, is kerberos very sensitive to version changes? It's not supposed to be, and usually isn't. Barring bugs, of course. If you can get a packet capture of a client request, we can examine the first few bytes to check what's triggering the failure. tcpdump says its a V5 packet. I have captured the entire login/reset failure and can email it to you directly if you wish. Sure. The first four bytes encode the message length (the first two bytes) and the protocol version number (the next two), so just that part should actually be enough to verify. HTH, Nalin ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Change Password problems (Unsupported Version)
On Wed, Sep 28, 2011 at 09:38:33PM +0200, Jakub Hrozek wrote: He said he was updating the passwords with kpasswd, which should bypass the pam stack and talk to the kpasswd deamon directly, right? The users who can change their passwords can log in and do so with kpasswd, but the ones who can't change their passwords can't log in to run kpasswd because the login-time password change (which goes through PAM) is failing. I expect that users who attempt to change their passwords with the passwd command are also triggering the same bug. Nalin ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Change Password problems (Unsupported Version)
On Tue, Sep 27, 2011 at 03:24:24PM +0800, Goff, Raal wrote: My IPA 2.0 master-slave setup has been working fine up until this week when users started getting problems updating their password due to expiry. Users get the following error when using kpasswd to update their passwords: kinit: krb5_get_init_creds: Unable to reach any changepw server in realm EXAMPLE.COM The only error I seem to find in the logs is unhelpful: Sep 27 15:16:12 ipa1 kpasswd[2689]: Unsupported version Sep 27 15:16:43 ipa1 kpasswd[2692]: Unsupported version Those correlate - the ipa_kpasswd daemon logs these messages when it sees a password-change request with an internal version number that doesn't match the version of the protocol that it handles. The client gets no reply, and because it's connectionless, it assumes that it was not able to contact a server. Additionally, it seems some users can reset their passwords, but the error still appears in the logs, and on the client software: Sep 27 15:08:52 ipa1 kpasswd[2630]: Unsupported version Sep 27 15:09:23 ipa1 kpasswd[2633]: Unsupported version Sep 27 15:09:54 ipa1 kpasswd[2637]: Password change succeeded Are the users who can change their passwords using different client software (specifically, versions of Kerberos, which supplies the kpasswd command) compared to the users who can't? If you can get a packet capture of a client request, we can examine the first few bytes to check what's triggering the failure. HTH, Nalin ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] FreeIPA for Linux desktop deployment
On Thu, May 12, 2011 at 07:02:27PM -0700, nasir nasir wrote: Thanks for the reply Rob ! I had tried with all the log files you mentioned and had kept most of them in debug mode. Tried again now. The only error or clue I could see was the following I already mentioned in my previous mail, oddjob-mkhomedir[17823]: error setting permissions on /home/nasir: Operation not permitted The helper runs as root -- does the root user on your client system have the ability to remotely write to that filesystem over NFS? Nalin ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Problem with KRB DNS discovery (i think)
On Wed, Nov 25, 2009 at 06:42:16PM +0100, Tomasz 'Zen' Napierala wrote: Dnia 2009-11-25, śro o godzinie 15:50 +0100, Tomasz Z. Napierala pisze: Hi, I'm getting problems installing clients with default ipa-client-install values. Relam and domain are both discovered successfully but then after issuing kinit admin I'm getting: kinit(v5): Cannot resolve network address for KDC in realm QXLTECH while getting initial credentials My krb5.conf looks like this: [libdefaults] default_realm = QXLTECH dns_lookup_realm = true dns_lookup_kdc = true ticket_lifetime = 24h forwardable = yes [domain_realm] .dc2 = QXLTECH dc2 = QXLTECH [snip] I dogged little bit deeper and straced kinit. It looks like kinit is picking up wrong domain name. My realm is QXLTECH but domain name .dc2 or .dc3 Kinit is requesting _kerberos._tcp.QXLTECH How can I change it? I wouldn't recommend trying, not exactly. The client's doing what the standards say it should, but that might be confusing in cases where the realm name and domain name are different because the query is based on the realm name and not the domain name. To understand it, it's useful to know that there are two kinds of DNS queries being made here: 1. Kerberos is using DNS to figure out the name of the realm to which a given host belongs, and for that it's going to use the hostname and domain name to form its queries. For the configuration you provided, the records in DNS would probably look something like this: _kerberos.dc2. IN TXT QXLTECH 2. Kerberos is using DNS to get the hostname of a KDC for the realm. The important detail is that it uses the realm name and not a domain name to form the query, and I suspect that's what's missing in your setup. The records in DNS are regular SRV records, and they'd probably look like this: _kerberos._udp.qxltech.IN SRV 0 0 88 kdc-host.dc2. _kerberos._tcp.qxltech.IN SRV 0 0 88 kdc-host.dc2. _kerberos-master._udp.qxltech. IN SRV 0 0 88 kdc-host.dc2. _kerberos-master._tcp.qxltech. IN SRV 0 0 88 kdc-host.dc2. _kpasswd._udp.qxltech. IN SRV 0 0 464 kdc-host.dc2. _kpasswd._tcp.qxltech. IN SRV 0 0 464 kdc-host.dc2. It's pretty common to have the DNS domain name and the Kerberos realm name differ only by case (for example, example.com as a domain name, and EXAMPLE.COM as the realm), or to have the domain name look like a subdomain of the realm name (for example, devel.example.com for the domain name, EXAMPLE.COM for the realm) so most people end up not having to care that the second case uses the realm rather than the DNS domain name. But it looks as though, in your configuration, you do. HTH, Nalin ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
