Re: [Freeipa-users] ipa server-del
On 05/04/2017 12:41 AM, Ian Harding wrote: Is there any way this can be made to work? This server does not exist in real life or seemingly in FreeIPA, but a ghost of it does. ianh@vm-ian-laptop:~$ ipa server-find freeipa-dal.bpt.rocks 1 IPA server matched Server name: freeipa-dal.bpt.rocks Min domain level: 0 Max domain level: 0 Number of entries returned 1 ianh@vm-ian-laptop:~$ ipa server-del freeipa-dal.bpt.rocks Removing freeipa-dal.bpt.rocks from replication topology, please wait... ipa: ERROR: freeipa-dal.bpt.rocks: server not found ianh@vm-ian-laptop:~$ ipa server-del freeipa-dal.bpt.rocks --force Removing freeipa-dal.bpt.rocks from replication topology, please wait... ipa: ERROR: freeipa-dal.bpt.rocks: server not found ianh@vm-ian-laptop:~$ ipa server-del freeipa-dal.bpt.rocks --force --continue Removing freeipa-dal.bpt.rocks from replication topology, please wait... ipa: WARNING: Forcing removal of freeipa-dal.bpt.rocks - Deleted IPA server "" - Failed to remove: freeipa-dal.bpt.rocks ianh@vm-ian-laptop:~$ - Ian This looks like a bug to me. Probably some LDAP search ended with "not found" result which then was incorrectly interpreted as "server not found". To know where the issue is it would help switch IPA framework on server to debug mode [1] and provide httpd/error_log and dirsrv/$domain/access log from time of execution of the command. [1] https://www.freeipa.org/page/Troubleshooting#Administration_Framework -- Petr Vobornik -- 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] I think I lost my CA...
On 04/28/2017 02:57 PM, Bret Wortman wrote: Flo, I did find that issue and made those corrections to our /etc/hosts file, but the problem persists. Thanks for the idea! after the change did you restart pki? Bret On 04/27/2017 03:42 AM, Florence Blanc-Renaud wrote: On 04/26/2017 04:33 PM, Bret Wortman wrote: So I can see my certs using cert-find, but can't get details using cert-show or add new ones using cert-request. # ipa cert-find : -- Number of entries returned 385 -- # ipa cert-show 895 ipa: ERROR: Certificate operation cannot be completed: Unable to communicate with CMS (503) # ipa cert-show 1 (which does not exist) ipa: ERROR: Certificate operation cannot be completed: Unable to communicate with CMS (503) # ipa cert-status 895 ipa: ERROR: Certificate operation cannot be completed: Unable to communicate with CMS (503) # Is this an IPV6 thing? Because ipactl shows everything green and certmonger is running. Hi Bret, the issue looks similar to https://pagure.io/freeipa/issue/6575 and https://pagure.io/dogtagpki/issue/2570 which were IPv6 related. Note that IPv6 must be enabled on the machine but IPA does not require an IPv6 address to be configured (except for the loopback). You can check the following: - is PKI listening to port 8009 on IPv6 or IPv4 interface? sudo netstat -tunpl | grep 8009 tcp6 0 0 127.0.0.1:8009 :::* LISTEN 10749/java - /etc/pki/pki-tomcat/server.xml defines a redirection from port 8009 to 8443, and the "address" part is important: In the above example, it will be using localhost which can resolve either to IPv4 or IPv6. - /etc/hosts must define the loopback addresses with 127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6 HTH, Flo. Bret On 04/26/2017 09:03 AM, Bret Wortman wrote: Digging still deeper: # ipa cert-request f.f --principal=HTTP/`hostname`@DAMASCUSGRP.COM ipa: ERROR: Certificate operation cannot be completed: Unable to communicate with CMS (503) Looks like this is an HTTP error; so is it possible that my IPA thinks it has a CA but there's no CMS available? On 04/26/2017 08:41 AM, Bret Wortman wrote: Using the firefox debugger, I get these errors when trying to pop up the New Certificate dialog: Empty string passed to getElementById(). (5) jquery.js:4:1060 TypeError: u is undefined app.js:1:362059 Empty string passed to getElementById(). (5) jquery.js:4:1060 TypeError: t is undefined app.js:1:217432 I'm definitely not a web kind of guy so I'm not sure if this is helpful or not. This is on 4.4.0, API Version 2.213. Bret On 04/26/2017 08:35 AM, Bret Wortman wrote: Good news. One of my servers _does_ have CA installed. So why does "Action -> New Certificate" not do anything on this or any other server? Bret On 04/25/2017 02:52 PM, Bret Wortman wrote: I recently had to upgrade all my Fedora IPA servers to C7. It went well, and we've been up and running nicely on 4.4.0 on C7 for the past month or so. Today, someone came and asked me to generate a new certificate for their web server. All was good until I went to the IPA UI and tried to perform Actions->New Certificate, which did nothing. I tried each of our 3 servers in turn. All came back with no popup window and no error, either. I suspect the problem might be that we no longer have a CA server due to the method I used to upgrade the servers. I likely missed a "--setup-ca" in there somewhere, so my rolling update rolled over the CA. What's my best hope of recovery? I never ran this before, so I'm not sure if this shows that I'm missing a CA or not: # ipa ca-find 1 CA matched Name: ipa Description IPA CA Authority ID: 3ce3346[...] Subject DN: CN=Certificate Authority, O=DAMASCUSGRP.COM Issuer DN: CN=Certificate Authority,O=DAMASCUSGRP.COM Number of entries returned 1 # ipa ca-add dg --desc "Damascus Group" --subject "CN=DG CA, O=DAMASCUSGRP.COM" ipa: ERROR: Failed to authenticate to CA REST API # klist Ticket cache: KEYRING:persistent:0:0 Default principal: ad...@damascusgrp.com Valid starting Expires Service principal 04/25/2017 18:48:26 04/26/2017 18:48:21 krbtgt/damascusgrp@damascusgrp.com # What's my best path of recovery? -- *Bret Wortman* The Damascus Group -- Petr Vobornik Associate Manager, Engineering, Identity Management Red Hat -- 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] LDAP size limit and the FreeIPA web UI
On 05/02/2017 10:50 PM, Jay Fenlason wrote: One of my users is having trouble because the FreeIPA web interface does not work well with a DNS zone that contains more than 2000 entries. When he goes to Network Services->DNS->DNS Zones and selects the problematic zone, he gets an error popup saying the results were truncated because the number of entries exceeds the LDAP server's search limit. I went in to IPA Server->Configuration and changed the Search size limit, but raising it over 2000 requires manually modifying the LDAP server configuration. Are there any plans to improve the web UI so that it does not require such a large size limit when viewing a DNS zone? Are there other GUI tools that can be used to view/edit the DNS zone data (and that don't also suffer from hitting these search size limits)? I'm using ipa-server-4.4.0-14.el7.centos.6.x86_64 if it matters. -- JF Web UI has the same size limits which are imposed by LDAP server for the authenticated user. In 4.5 version the warning was changed to be less annoying. There are currently no specific plans to change Web UI in this area. A think which was considered is to disable paging for post pages (e.g. user and host search) and rely more on size-limits and searching. The reasoning is that browser through a lot of records is not very usable and it is better to search. So I would ask in different way. How would you envision the Web UI should behave for so many records? E.g. just in DNS area. -- Petr Vobornik -- 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] Manual Cleanup
On 03/16/2017 07:14 PM, Ian Harding wrote: I've made some progress. But I have one zombie replication agreement to kill, I just don't know the syntax. The output listed below is not replication agreement. But there is reference to RUV. freeipa-dal.bpt.rocks does not exist. I want all references to it to go away. How would I do that with ldapmodify? I wouldn't delete the entry below because cn=replica,cn=o\3Dipaca,cn=mapping tree,cn=config is a container for CA replication agreements and it should stay there. Btw, there should also be one for "domain" replication agreements. But in general, you could use ldapdelete command. If you want to investigate pure ldap data, then information about IPA masters is also stored in cn=masters,cn=ipa,cn=etc,dc=example,dc=test . This is the place where ipa server-find gets its info. Thanks! [root@freeipa-sea slapd-BPT-ROCKS]# ldapsearch -D "cn=directory manager" -w ... -b "o=ipaca" "(&(objectclass=nstombstone)(nsUniqueId=---))" nscpentrywsi # extended LDIF # # LDAPv3 # base
Re: [Freeipa-users] Adjusting nsslapd-cachememsize
On 03/17/2017 03:20 AM, Lachlan Musicman wrote: While going through the logs on the FreeIPA server, I noticed this: WARNING: changelog: entry cache size 2097152 B is less than db size 12804096 B; We recommend to increase the entry cache size nsslapd-cachememsize. I have found a number of documents: What it is: https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/8.0/html/Configuration_and_Command_Reference/Configuration_Command_File_Reference-Database_Attributes_under_cnNetscapeRoot_cnldbm_database_cnplugins_cnconfig_and_cnUserRoot_cnldbm_database_cnplugins_cnconfig-nsslapd_cachememsize.html How to tune it: https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/8.1/html/Administration_Guide/memoryusage.html etc etc. I have no idea of what the secret password is for the "cn=directory manager" and can't find any information about where I might find it or where or when it might have been set anywhere. I have found a number of likely candidates, but none have worked. When you install a first IPA server, run ipa-kra-install, or install a replica (before 4.4 replica promotion) you typically write that password. I.e. in ipa-server-install you provide 2 passwords, one for directory manager second for admin user. I found this page: https://www.freeipa.org/page/Howto/Change_Directory_Manager_Password but I'd prefer to not change the password if possible. cheers L. -- The most dangerous phrase in the language is, "We've always done it this way." - Grace Hopper -- Petr Vobornik Associate Manager, Engineering, Identity Management Red Hat, Inc. -- 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] Read-only replicas?
On 03/13/2017 03:17 PM, Stephen wrote: Is there read-only replica support in freeipa? The use case is a dmz. Thanks... Hello Stephen, No, FreeIPA doesn't support read only replicas yet. Could you write your use case in more details in: https://pagure.io/freeipa/issue/5569 or https://bugzilla.redhat.com/show_bug.cgi?id=1291240 It will help us prioritize and know what you actually expect from the feature. Regards, -- Petr Vobornik -- 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] Issue upgrading freeipa to ipa-server-4.4.0-14.el7.centos.4.x86_64
ns] [Ensuring minimal number of connections] [Enabling serial autoincrement in DNS] [Updating GSSAPI configuration in DNS] [Updating pid-file configuration in DNS] [Checking global forwarding policy in named.conf to avoid conflicts with automatic empty zones] Changes to named.conf have been made, restart named [Upgrading CA schema] CA schema update complete (no changes) [Verifying that CA audit signing cert has 2 year validity] [Update certmonger certificate renewal configuration to version 5] [Enable PKIX certificate path discovery and validation] PKIX already enabled [Authorizing RA Agent to modify profiles] [Authorizing RA Agent to manage lightweight CAs] [Ensuring Lightweight CAs container exists in Dogtag database] [Adding default OCSP URI configuration] [Ensuring CA is using LDAPProfileSubsystem] [Migrating certificate profiles to LDAP] [Ensuring presence of included profiles] [Add default CA ACL] Default CA ACL already added [Set up lightweight CA key retrieval] Creating principal Retrieving keytab IPA server upgrade failed: Inspect /var/log/ipaupgrade.log and run command ipa-server-upgrade manually. Unexpected error - see /var/log/ipaupgrade.log for details: OSError: [Errno 2] No such file or directory: '/etc/pki/pki-tomcat/dogtag.keytab' The ipa-server-upgrade command failed. See /var/log/ipaupgrade.log for more information [root@o-ipa01-r ~]# Everything seems to be working as normal, but this error message worries me a bit since this is my only ipa server (setting up a secondary master have been on my todo list). Can you help me troubleshoot this? Or should I just setup a replica and propagate it to primary node for all clients and then reinstall the one that have problem? Might be worth to check associated pw policies. What is the password policy associated with dogtag service ( krbprincipalname=dogtag/o-ipa01-r.ovirt.netnerdz...@netnerdz.secn=services,cn=accounts,$SUFFIX and how does it look (attribute krbPwdPolicyReference) Does it point to "cn=Default Kerberos Service Password Policy,cn=services,cn=accounts,$SUFFIX", e.g. as defined in (line 45)?: https://pagure.io/freeipa/c/6f1d927467e7907fd1991f88388d96c67c9bff61 Does this policy exist? Also look to /var/log/krb5kdc.log for any interesting messages Thank you in advance! //Robert -- Petr Vobornik -- 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] Migration of FreeIPA issue tracker - Trac and git repo to pagure.io
On 02/27/2017 12:46 PM, Petr Vobornik wrote: Hello list, today and tomorrow a migration of FreeIPA issue tracker[1] and git repo will take place. It is due to FedoraHosted sunset [2]. Both will be migrated to pagure.io [3]. During this migration it won't be possible to add new tickets and comments to Trac or Pagure. [1] https://fedorahosted.org/freeipa/ [2] https://communityblog.fedoraproject.org/fedorahosted-sunset-2017-02-28/ [3] https://pagure.io/ Thank you for understanding, Issue tracker and git repo were migrated. They can be used now. https://pagure.io/freeipa Additional steps will follow - redirection of old URLs to new - sync with github -- Petr Vobornik Associate Manager, Engineering, Identity Management Red Hat, Inc. -- 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] CentOS 6 -> 7 migration
On 02/26/2017 04:58 PM, Rob Verduijn wrote: Sounds feasable, however I'm not sure which solution entails the most work. +1 Just in case, I'll mention migration documentation: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/upgrading.html#migrating-ipa-proc There are some manual steps regarding CA which should not be skipped. In step 3 you loose all the extra functionalities( cups/squid/ntp ) as well, while these stay preserved by a p2v including a nice backup. You do need a backup of all the functions before proceeding with step3. Rob Verduijn 2017-02-26 14:40 GMT+01:00 Ian Pilcher <arequip...@gmail.com <mailto:arequip...@gmail.com>>: On 02/26/2017 05:08 AM, Rob Verduijn wrote: You should consider setting up a temporary vm to migrate from. On one of your client systems, I assume you got at least 1 ipa client Try looking at http://libguestfs.org/virt-p2v.1.html <http://libguestfs.org/virt-p2v.1.html> to migrate your current system to a vm (side effect : instant full backup) When you got the vm up and running you can reinstall your main system with the new os and ipa. Then replicate the old ipa to the new one. Hmm. The system that runs IPA is the "network server" in my home network. It runs various services -- DNS, NTP, CUPS, squid, etc. -- as well as routing between various VLANs. So simply P2V'ing it would be a major project in its own right. What about this, though ... 1. Set up a new CentOS 7 VM running IPA 2. Replicate the IPA data from the old CentOS 6 system to the VM. 3. Install CentOS 7 on the original system 4. Replicate the IPA data back from the VM Will this work? -- Ian Pilcher arequip...@gmail.com <mailto:arequip...@gmail.com> "I grew up before Mark Zuckerberg invented friendship" -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users <https://www.redhat.com/mailman/listinfo/freeipa-users> Go to http://freeipa.org for more info on the project -- Petr Vobornik Associate Manager, Engineering, Identity Management Red Hat, Inc. -- 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] unable to decode: {replica
On 02/26/2017 11:35 AM, lejeczek wrote:
hi everyone
I first time see:
unable to decode: {replica 60} 586eaffd000a003c 586eaffd000a003c
Replica Update Vectors:
on all four servers. What would be a correct troubleshooting and fixing this
problem?
many thanks,
L.
Hello,
what is the version and OS of your IPA servers and DS?
$ rpm -q ipa-server freeipa-server 389-ds-base
Similar issues happened last year, you can search the archives for
"unable to decode" but a 389-ds fix improved the situation. So if you
have older version then maybe update and then manual cleanup of RUVs
might help.
--
Petr Vobornik
--
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
[Freeipa-users] Migration of FreeIPA issue tracker - Trac and git repo to pagure.io
Hello list, today and tomorrow a migration of FreeIPA issue tracker[1] and git repo will take place. It is due to FedoraHosted sunset [2]. Both will be migrated to pagure.io [3]. During this migration it won't be possible to add new tickets and comments to Trac or Pagure. [1] https://fedorahosted.org/freeipa/ [2] https://communityblog.fedoraproject.org/fedorahosted-sunset-2017-02-28/ [3] https://pagure.io/ Thank you for understanding, -- Petr Vobornik Associate Manager, Engineering, Identity Management Red Hat, Inc. -- 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] WEB UI - wrong fonts or incomplete page loaded
On 02/24/2017 05:13 PM, Iulian Roman wrote:
On Fri, Feb 24, 2017 at 4:55 PM, Petr Vobornik <pvobo...@redhat.com
<mailto:pvobo...@redhat.com>> wrote:
On 02/24/2017 12:15 PM, Iulian Roman wrote:
Hello,
After a successful installation of the ipa-server when i try to login
via WEB UI
i've noticed that the web page looks strange (wrong fonts and page
seems not
completely/correctly loaded).
The network debugger in chrome/firefox does
So it won't be browser or extension related. The only possibility is to have
same extension on both browsers.
display 2 errors :
- json /ipa/session/ 401 Unauthorized
This is expected.
- login _kerberos?=... net::ERR_ACCESS_DENIED
This one should return also "401 Unauthorized" if you don't have SSO
configured on browser or SSO(kerberos) ticket.
net::ERR_ACCESS_DENIED indicates something wrong. Maybe some other software
interferes in the communication with server.
What OS it is? Could there be an overzealous antivirus (the web check
part). Or maybe a custom proxy setting?
it behaves the same from all browsers (firefox,chrome) and from both Linux and
windows. i do use proxy, but trying with the firefox directly from the ipa
server - therefore without proxy - does have the same result.
I do not intend to use SSO for login into WEBUI (although it is the
default in
the ipa version i am using) but apparently a supported method to
disable it is
not known.
Right, it is not currently possible. I've opened RFE ticket.
https://fedorahosted.org/freeipa/ticket/6709
<https://fedorahosted.org/freeipa/ticket/6709> Please comment if you use
case is different than the proposed user story.
I can login with user and password but the WEB UI is almost unusable
because of wrongly loaded page .
I wonder if something did not temper in the loaded files. If all files are
loaded correctly and if it is fresh install(to mitigate possibility of old
cache) then it is weird. Maybe it is the antivirus.
i wonder too. the strange thing is that from the same browser i can access
properly a different ipa server (which i've configured some time ago).
Do you have some Web UI plugin installed on IPA server?
it is default installation. How can i check which plugins are installed ?
Plugins are in /usr/share/ipa/ui/js/plugins/ if the directory is empty
then there is no plugin.
But plugin would not cause:
login _kerberos?=... net::ERR_ACCESS_DENIED
Did anyone experience the same issue and is there any fix/solution for
that ?
--
Petr Vobornik
Associate Manager, Engineering, Identity Management
Red Hat, Inc.
--
Petr Vobornik
Associate Manager, Engineering, Identity Management
Red Hat, Inc.
--
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] WEB UI - wrong fonts or incomplete page loaded
On 02/24/2017 12:15 PM, Iulian Roman wrote: Hello, After a successful installation of the ipa-server when i try to login via WEB UI i've noticed that the web page looks strange (wrong fonts and page seems not completely/correctly loaded). The network debugger in chrome/firefox does So it won't be browser or extension related. The only possibility is to have same extension on both browsers. display 2 errors : - json /ipa/session/ 401 Unauthorized This is expected. - login _kerberos?=... net::ERR_ACCESS_DENIED This one should return also "401 Unauthorized" if you don't have SSO configured on browser or SSO(kerberos) ticket. net::ERR_ACCESS_DENIED indicates something wrong. Maybe some other software interferes in the communication with server. What OS it is? Could there be an overzealous antivirus (the web check part). Or maybe a custom proxy setting? I do not intend to use SSO for login into WEBUI (although it is the default in the ipa version i am using) but apparently a supported method to disable it is not known. Right, it is not currently possible. I've opened RFE ticket. https://fedorahosted.org/freeipa/ticket/6709 Please comment if you use case is different than the proposed user story. I can login with user and password but the WEB UI is almost unusable because of wrongly loaded page . I wonder if something did not temper in the loaded files. If all files are loaded correctly and if it is fresh install(to mitigate possibility of old cache) then it is weird. Maybe it is the antivirus. Do you have some Web UI plugin installed on IPA server? Did anyone experience the same issue and is there any fix/solution for that ? -- Petr Vobornik Associate Manager, Engineering, Identity Management Red Hat, Inc. -- 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] FreeIPA 4.2 CA issues
On 01/25/2017 02:30 PM, Gendy Tartovsky wrote: > Hi, > > I'm having a PKI-tomcat issue that started after upgrade. > My configuration has 4 servers with CA, where servers 2, 3 and 4 are > replicated > from the first one. > At first it didn't cause much trouble since all the issue came down to > pki-tomcat getting to start about 2 minutes. > But it seems that problem is progressed a lot and is causing issues in > multiple > parts of the system. > > After upgrading FreeIPA from 4.1 to 4.2 ipactl would not on the first node > start without the --ignore-service-failures. > > I found that in the menu Authentication-->Certificates > I have multiple certificates for same hosts in some cases there were up to > 30 > duplicates per host and it is unclear what is generating them. > > Next issue is that if I try to add a new replica with ipa-replica-prepare > utility > I get an error: "Failed to generate certificate" > > And the last problem I found is that I am unable to restore a backup. > The ipa-restore utility is able to unpack the backup but once I try to start > FreeIPA on a new node > the pki-tomcat fails to start. And I see this message in debug: > > ipa: DEBUG: Waiting for CA to start... > ipa: DEBUG: Starting external process > ipa: DEBUG: args='/usr/bin/wget' '-S' '-O' '-' '--timeout=30' > '--no-check-certificate' 'https://:8443/ca/admin/ca/getStatus' > ipa: DEBUG: Process finished, return code=8 > > > In the /var/log/dirsrv/slapd-XXX/errors I see a lot of these > NSMMReplicationPlugin - process_postop: Failed to apply update > (57c3cc550002000d) error (-1). Aborting replication session(conn=272420 > op=6) > > but I'm not sure if it is directly related to the problem. > > In /var/log/pki/pki-tomcat/ca/debug I see a lot of these messages: > Can't create master connection in LdapBoundConnFactory::getConn! Could not > connect to LDAP server host bos-admin1.hq.datarobot.com > <http://bos-admin1.hq.datarobot.com> port 636 Error > netscape.ldap.LDAPException: > IO Error creating JSS SSL Socket > > My guess was that the CA certificate got expired, so I tried to run > 'ipa-cacert-manage renew' > but it failed with this message: > > Resubmitting certmonger request '20151222031110' timed out, please check the > request manually > > > Don't really know what else to try right now. > Could you check: Is directory server listening on ports 389 and 636? Is PKI server listening on port 8009 i.e. if you are hitting bug https://fedorahosted.org/freeipa/ticket/6575 You can verify if certs are expired by running # getcert list And check expiration date. -- Petr Vobornik -- 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] modify schema - add group email and display attribute
On 01/11/2017 01:58 PM, Sandor Juhasz wrote:
> Ok,
>
> OID - check
> ldapmodify - check
> python scripts - check
> These works on both ipa 3.x and ipa 4.x.
> So the basic functionality is there for the new object class.
>
> js - i am stuck with, i have created the js files for the plugin, see below.
>
> But i don't know how to generate the the index. Also i might be completely
> wrong.
>
> On ipa 3.x the js files are there, most probably the groups.js would exist as
> i
> expect it.
> But on the other hand on the ipa 4.x there is nothing but freeipa/core.js is
> there.
You don't need to generate plugin index, it is generated automatically.
Just:
mkdir /usr/share/ipa/ui/js/plugins/myplugin
cp myplugin.js /usr/share/ipa/ui/js/plugins/myplugin
It should be automatically picked up by Web UI.
It will work only in RHEL 7/CentOS 7(FreeIPA 3.3+). Not RHEL 6(sort of
3.0/3.1/3.2)
On RHEL 6, there is /usr/share/ipa/ui/ext/extension.js which can contain
custom content to extend UI, but writing a plugin for it is much more
complicated so I'd rather avoid it.
>
> Here is the plugin, i am trying to use:
> define([
>'freeipa/phases',
>'freeipa/group'],
>function(phases, group_mod) {
> // helper function
> function get_item(array, attr, value) {
>for (var i=0,l=array.length; i<l; i++) {
> if (array[i][attr] === value) return array[i];
>}
>return null;
> }
> var groupmail_plugin = {};
> // adds 'mail' field into group details facet
> groupmail_plugin.add_group_mail_pre_op = function() {
>var facet = get_item(group_mod.entity_spec.facets, '$type', 'details');
>var section = get_item(facet.sections, 'name', 'identity');
>section.fields.push({
> name: 'mail',
> label: 'Mail'
>});
>return true;
> };
> phases.on('customization', groupmail_plugin.add_group_mail_pre_op);
> return groupmail_plugin;
> });
>
>
> *Sándor Juhász*
> System Administrator
> *ChemAxon**Ltd*.
> Building Hx, GraphiSoft Park, Záhony utca 7, Budapest, Hungary, H-1031
> Cell: +36704258964
>
>
> *From: *"Brian Candler" <b.cand...@pobox.com>
> *To: *"Sandor Juhasz" <sjuh...@chemaxon.com>
> *Cc: *freeipa-users@redhat.com
> *Sent: *Monday, January 2, 2017 6:41:02 PM
> *Subject: *Re: [Freeipa-users] modify schema - add group email and display
> attribute
>
> On 02/01/2017 11:53, Sandor Juhasz wrote:
> > I would be really happy if anybody could assign an OID for the new
> > objectcalss
>
> You can get your own enterprise OID for free from here:
>
> http://pen.iana.org/pen/PenApplication.page
>
> Note that you only get one, so it's up to you to subdivide the space.
> For example: if you get 1.3.6.1.4.1.9, then you might decide to use:
>
> 1.3.6.1.4.1.9.1 = LDAP object classes
>
> 1.3.6.1.4.1.9.1.1 = myMailObjectClass
>
> 1.3.6.1.4.1.99999.1.2 = someOtherObjectClass
>
> 1.3.6.1.4.1.9.2 = LDAP attributes
>
> 1.3.6.1.4.1.9.2.1 = mySpecialAttribute
>
> then later you can assign under 1.3.6.1.4.1.9.3 for something else
> that needs OIDs (e.g. SNMP MIBs) and so on.
>
>
>
--
Petr Vobornik
--
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] pki-tomcat failure
at > org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:288) > at > org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:285) > at java.security.AccessController.doPrivileged(Native Method) > at javax.security.auth.Subject.doAsPrivileged(Subject.java:549) > at > org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:320) > at > org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:175) > at > org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:124) > at > org.apache.catalina.core.StandardWrapper.initServlet(StandardWrapper.java:1270) > at > org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1195) > at > org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:1085) > at > org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:5318) > at > org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5610) > at > org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:147) > at > org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:899) > at > org.apache.catalina.core.ContainerBase.access$000(ContainerBase.java:133) > at > org.apache.catalina.core.ContainerBase$PrivilegedAddChild.run(ContainerBase.java:156) > at > org.apache.catalina.core.ContainerBase$PrivilegedAddChild.run(ContainerBase.java:145) > at java.security.AccessController.doPrivileged(Native Method) > at > org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:873) > at > org.apache.catalina.core.StandardHost.addChild(StandardHost.java:652) > at > org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:679) > at > org.apache.catalina.startup.HostConfig$DeployDescriptor.run(HostConfig.java:1966) > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > Internal Database Error encountered: Could not connect to LDAP server > host ipa001.mgmt.local.com port 636 Error netscape.ldap.LDAPException: > Authentication failed (48) > at com.netscape.cmscore.dbs.DBSubsystem.init(DBSubsystem.java:676) > > The only connection attempt I can find relating to err=48 in the slapd > access log is - > > > [10/Jan/2017:18:21:08.884446519 +] conn=59668 fd=83 slot=83 SSL > connection from 10.220.6.250 to 10.220.6.250 > [10/Jan/2017:18:21:08.898844561 +] conn=59668 TLS1.2 256-bit AES > [10/Jan/2017:18:21:08.917314723 +] conn=59668 op=0 BIND dn="" > method=sasl version=3 mech=EXTERNAL > [10/Jan/2017:18:21:08.919725280 +] conn=59668 op=0 RESULT err=48 > tag=97 nentries=0 etime=0 > [10/Jan/2017:18:21:09.590236408 +] conn=59637 op=88 EXT > oid="2.16.840.1.113730.3.5.12" name="replication-multimaster-extop" > > We recent upgraded ipa from 4.2 to 4.4 and I wonder if that broke something. > > ipa --version > VERSION: 4.4.0, API_VERSION: 2.213 > > The /etc/ca.crt cert was originally created on an ipa 3.3 server that no > longer exists, I don't know if that's relevant. > > Anyway, I'm stumped on how to fix this so could anyone please help. > > Many thanks > > Bob > -- Petr Vobornik -- 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] FreeIpa client can't execute any command
On 01/09/2017 02:56 PM, Андрей Ривкин wrote: > Hello everyone! > > I'm new to FreeIpa, so if my question is very simple just point me to the > documentation. > > I've installed FreeIpa on host demo3.xxx.com <http://demo3.xxx.com>. > Then registred some other host demo5.xxx.com <http://demo5.xxx.com>. I've > used > ipa add host command. > Then installed ipa-client and ipa-admin-tools demo5. > Checked that they worked and were able to execute commands like kinit and ipa > host-find. > > On the host demo3 I've restarted service ipa (service ipa restart). > Now I'm able to execute ipa host-find on demo3, but not able to execute this > command on demo3. > I've done kinit by 'someadmin'. > All ipa commands not working: > > > [root@demo5 ~]# ipa -v -d > ipa: DEBUG: Starting external process > ipa: DEBUG: args=keyctl search @s user ipa_session_cookie:somead...@xxx.com > <mailto:ipa_session_cookie%3asomead...@xxx.com> > ipa: DEBUG: Process finished, return code=1 > ipa: DEBUG: stdout= > ipa: DEBUG: stderr=keyctl_search: Required key not available > > ipa: DEBUG: failed to find session_cookie in persistent storage for principal > 'somead...@xxx.com <mailto:somead...@xxx.com>' > ipa: INFO: trying https://demo3.xxx.com/ipa/json > ipa: DEBUG: Created connection context.rpcclient_41215888 > ipa: INFO: Forwarding 'schema' to json server 'https://demo3.xxx.com/ipa/json' > ipa: DEBUG: Destroyed connection context.rpcclient_41215888 > ipa: ERROR: Service 'h...@demo3.xxx.com <mailto:h...@demo3.xxx.com>' not > found > in Kerberos database > > > It looks like my client is not connected to my server. > Any ideas how to debug this situation? > > P.S. Hosts - Centos 7. DNS on demo3. > > Regards, > Andrey > Does following sequence work the same way on both demo3 and demo5? $ kdestroy -A $ kinit someadmin $ kvno HTTP/demo3.xxx.com Does `ipactl status` show that all services are running fine? -- Petr Vobornik -- 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 replica installation help
On 01/05/2017 07:10 AM, Ben .T.George wrote: > HI > > yes i did the same and still port is not listening. > > [root@zkwipamstr01 ~]# cat /etc/hosts > 127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 > ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6 > 10.151.4.64 zkwipamstr01.kw.example.com <http://zkwipamstr01.kw.example.com> > > zkwipamstr01 > 10.151.4.65 zkwiparepa01.kw.example.com <http://zkwiparepa01.kw.example.com> > > zkwiparepa01 > [root@zkwipamstr01 ~]# systemctl restart pki-tomcatd@pki-tomcat > [root@zkwipamstr01 ~]# netstat -tunap | grep 8009 > > > Regards > Ben Also IPv6 stack needs to be enabled. > > On Thu, Jan 5, 2017 at 9:03 AM, Fraser Tweedale <ftwee...@redhat.com > <mailto:ftwee...@redhat.com>> wrote: > > On Wed, Jan 04, 2017 at 03:12:12PM +0300, Ben .T.George wrote: > > HI > > > > port 8009 is not listening in master server > > > > and i added ::1 localhost localhost.localdomain localhost6 > > localhost6.localdomain6 in hosts file. > > > > Did you add this to the host file on the master (then `systemctl > restart pki-tomcatd@pki-tomcat` and confirm it is listening on port > 8009)? Or just the client you are trying to promote? > > It is needed on the master. Won't hurt to make this change to > /etc/hosts on both machines, though. > > HTH, > Fraser > > > still getting same error > > > > [28/44]: restarting directory server > > ipa : CRITICAL Failed to restart the directory server (Command > > '/bin/systemctl restart dirsrv@KW-EXAMPLE-COM.service' returned > non-zero > > exit status 1). See the installation log for details. > > [29/44]: setting up initial replication > > [error] error: [Errno 111] Connection refused > > Your system may be partly configured. > > Run /usr/sbin/ipa-server-install --uninstall to clean up. > > > > ipa.ipapython.install.cli.install_tool(Replica): ERROR[Errno 111] > > Connection refused > > ipa.ipapython.install.cli.install_tool(Replica): ERRORThe > > ipa-replica-install command failed. See > /var/log/ipareplica-install.log for > > more information > > > > > > Also ipv6 is disabled on both nodes > > > > Regards, > > Ben > > > > On Wed, Jan 4, 2017 at 2:05 PM, Petr Vobornik <pvobo...@redhat.com > <mailto:pvobo...@redhat.com>> wrote: > > > > > On 01/04/2017 10:59 AM, Ben .T.George wrote: > > > > HI > > > > > > > > i tried the method mentioned on that document and it end up with > below > > > error. My > > > > DNS is managed by external box and i dont want to create any DNS > record > > > on these > > > > servers. > > > > > > > > and the command which i tried is(non client server) > > > > > > > > ipa-replica-install --principal admin --admin-password P@ssw0rd > --domain > > > > kw.example.com <http://kw.example.com> <http://kw.example.com> > --server > > > zkwipamstr01.kw.example.com <http://zkwipamstr01.kw.example.com> > > > > <http://zkwipamstr01.kw.example.com > <http://zkwipamstr01.kw.example.com>> > > > > > > > > > > > > > > > > ipa : CRITICAL Failed to restart the directory server > (Command > > > > '/bin/systemctl restart dirsrv@KW-EXAMPLE-COM.service' returned > > > non-zero exit > > > > status 1). See the installation log for details. > > > >[29/44]: setting up initial replication > > > >[error] error: [Errno 111] Connection refused > > > > Your system may be partly configured. > > > > Run /usr/sbin/ipa-server-install --uninstall to clean up. > > > > > > > > ipa.ipapython.install.cli.install_tool(Replica): ERROR[Errno > 111] > > > Connection > > > > refused > > > > ipa.ipapython.install.cli.install_tool(Replica): ERRORThe > > > > ipa-replica-install command failed. See > /var/log/ipareplica-install.log > > > for more > > > > information > > > > > > This
Re: [Freeipa-users] ipa replica installation help
gt; > Replica creation using 'ipa-replica-prepare' to generate replica file > is supported only in 0-level IPA domain. > > The current IPA domain level is 1 and thus the replica must > be created by promoting an existing IPA client. > > To set up a replica use the following procedure: > 1.) set up a client on the host using 'ipa-client-install' > 2.) promote the client to replica running 'ipa-replica-install' > *without* replica file specified > > 'ipa-replica-prepare' is allowed only in domain level 0 > The ipa-replica-prepare command failed. > > > i have IPA master server without AD integration and DNS is managed by > 3rd party appliances. > > > > Regards, > Ben > > > > Hi Ben, > > If you installed IPA 4.4 server then domain level 1 is the default. This > domain level uses different mechanism to stand up replicas. See the latest > IdM documentation[1] for more details. > > [1] > > https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/creating-the-replica.html > > <https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/creating-the-replica.html> > > -- > Martin^3 Babinsky > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > <https://www.redhat.com/mailman/listinfo/freeipa-users> > Go to http://freeipa.org for more info on the project > > > > -- Petr Vobornik -- 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] how to make email as mandatory field before user creation
On 01/02/2017 08:46 PM, nirajkumar.si...@accenture.com wrote: > Hi Prtr, > > Can you please suggest how to do it with plugins and which plugin I need to > use and how to integrate that plugin with freeipa. > > Thanks > Niraj Disclaimer: the example below is not really save because it doesn't handle e.g. stageusers and it might not work with later releases of FreeIPA because IPA doesn't provide any supported plugin API yet. Example: https://pvoborni.fedorapeople.org/plugins/backend/zuserplugin.py Old(FreeIPA 3.3) extending guide: http://www.freeipa.org/images/5/5b/FreeIPA33-extending-freeipa.pdf > > -Original Message- > From: Petr Vobornik [mailto:pvobo...@redhat.com] > Sent: 02 January 2017 22:21 > To: Singh, NirajKumar <nirajkumar.si...@accenture.com>; > freeipa-users@redhat.com > Subject: Re: [Freeipa-users] how to make email as mandatory field before user > creation > > On 01/02/2017 05:00 PM, nirajkumar.si...@accenture.com wrote: >> Hi Team, >> >> Is there any way to make email as mandatory field before creating any >> user from WEBUI or Console? >> >> Thanks & Regards, >> >> Niraj Kumar Singh >> > > Hello Niraj, > > FreeIPA doesn't support such configuration out of the box. > > It is theoretically possible to implement IPA server side plugin to mark the > field as required. It may not be straightforward though. > > -- > Petr Vobornik > > > > This message is for the designated recipient only and may contain privileged, > proprietary, or otherwise confidential information. If you have received it > in error, please notify the sender immediately and delete the original. Any > other use of the e-mail by you is prohibited. Where allowed by local law, > electronic communications with Accenture and its affiliates, including e-mail > and instant messaging (including content), may be scanned by our systems for > the purposes of information security and assessment of internal compliance > with Accenture policy. > __ > > www.accenture.com > -- Petr Vobornik -- 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] FIPS 140-2 Compliance
On 01/03/2017 04:28 PM, Sean Conley wrote: > Good Morning! > > Happy New Year to you, and any news on getting to FIPS Compliance? > > *Michael Sean Conley* > > Principal Systems Engineer > > > Hello Sean, It's being actively developed and support of it will most likely be part of FreeIPA 4.5. -- Petr Vobornik -- 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] how to make email as mandatory field before user creation
On 01/02/2017 06:21 PM, Matt . wrote: > Doesn't get the user a default mailaddress when you add him under the > REALM domain ? By default user gets an email address but there ways to skip it: ipa user-add test2 --first Test --last Test --email= ipa config-mod --emaildomain= Btw, in Web UI, user adder dialog doesn't have email field. To add it there a Web UI plugin would be needed. > > 2017-01-02 17:50 GMT+01:00 Petr Vobornik <pvobo...@redhat.com>: >> On 01/02/2017 05:00 PM, nirajkumar.si...@accenture.com wrote: >>> Hi Team, >>> >>> Is there any way to make email as mandatory field before creating any user >>> from >>> WEBUI or Console? >>> >>> Thanks & Regards, >>> >>> Niraj Kumar Singh >>> >> >> Hello Niraj, >> >> FreeIPA doesn't support such configuration out of the box. >> >> It is theoretically possible to implement IPA server side plugin to mark >> the field as required. It may not be straightforward though. >> >> -- >> Petr Vobornik >> >> -- >> 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 > -- Petr Vobornik -- 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] how to make email as mandatory field before user creation
On 01/02/2017 05:00 PM, nirajkumar.si...@accenture.com wrote: > Hi Team, > > Is there any way to make email as mandatory field before creating any user > from > WEBUI or Console? > > Thanks & Regards, > > Niraj Kumar Singh > Hello Niraj, FreeIPA doesn't support such configuration out of the box. It is theoretically possible to implement IPA server side plugin to mark the field as required. It may not be straightforward though. -- Petr Vobornik -- 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] FreeIPA User Authorization Guidelines Required
On 12/20/2016 10:58 AM, nirajkumar.si...@accenture.com wrote: > Hi FreeIPA Team, > > We have performed installation of FreeIPA Master Server and Client Server. We > are successful with user creation with home directory and sudo configuration. > > Regarding Authentication we have some questions: > > 1.Can we implement authorized key authentication for these servers. Is there > any > way in FreeIPA we can automate the ppk key generation for each individual > user? FreeIPA/IdM supports central management of public SSH keys: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/user-keys.html > > 2.If Not Automated key generation what are the possible ways for more secured > authentication other than password authentication? It supports Two Factor Authentication via integrated OTP support or third party RADIUS server: OTP: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/otp.html RADIUS proxy: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/otp.html#migrating-proprietary-otp > > Thanks and Regards, > > Niraj Kumar Singh > > Mobile: +91-9663212985 > > Email: nirajkumar.si...@accenture.com <mailto:nirajkumar.si...@accenture.com> > > > > > This message is for the designated recipient only and may contain privileged, > proprietary, or otherwise confidential information. If you have received it > in > error, please notify the sender immediately and delete the original. Any > other > use of the e-mail by you is prohibited. Where allowed by local law, > electronic > communications with Accenture and its affiliates, including e-mail and > instant > messaging (including content), may be scanned by our systems for the purposes > of > information security and assessment of internal compliance with Accenture > policy. > ______ > > www.accenture.com > > > -- Petr Vobornik -- 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] Replica Creation Issue
On 12/14/2016 03:27 PM, Christian McNamara wrote: > Hi all, > > I recently inherited a FreeIPA system that I believe is running v3.0, and I'm > trying to upgrade to the latest version. Following documentation, I'm trying > to > create a replica but I'm running into problems connecting to the LDAP server. > Here's the output I get when trying to prepare a replica: > > $ sudo ipa-replica-prepare auth4.sshchicago.org > <http://auth4.sshchicago.org> --ip-address 172.31.31.36 > Directory Manager (existing master) password: > > Preparing replica for auth4.sshchicago.org <http://auth4.sshchicago.org> > from auth3.sshchicago.org <http://auth3.sshchicago.org> > preparation of replica failed: cannot connect to > u'ldaps://auth3.sshchicago.org <http://auth3.sshchicago.org>: > > > >7390': > LDAP Server Down > cannot connect to u'ldaps://auth3.sshchicago.org:7390 > <http://auth3.sshchicago.org:7390>': LDAP Server Down >File "/usr/sbin/ipa-replica-prepare", line 529, in > main() > >File "/usr/sbin/ipa-replica-prepare", line 391, in main > update_pki_admin_password(dirman_password) > >File "/usr/sbin/ipa-replica-prepare", line 247, in > update_pki_admin_password > bind_pw=dirman_password > >File "/usr/lib/python2.6/site-packages/ipalib/backend.py", line 63, in > connect > conn = self.create_connection(*args, **kw) > >File "/usr/lib/python2.6/site-packages/ipaserver/plugins/ldap2.py", > line > 846, > > > > in create_connection > self.handle_errors(e) > >File "/usr/lib/python2.6/site-packages/ipaserver/plugins/ldap2.py", > line > 736, > > > > in handle_errors > error=u'LDAP Server Down') > > > It says that our LDAP server is down, but it's trying to connect using the > wrong > port number. Our LDAP server runs on 389, not 7390, and I can't figure out > how > to specify this to the prepare script. > > Any ideas? > IPA 3.0 has 2 instances of directory server. One for domain data second for PKI CA data. IPA 4.x instances have them merged. So port 7390 is ldaps for of PKI-IPA DS instance, e.g. equivalent for 636 port of domain DS instance. Similar mapping is with 7389 and 389 ports. Therefore I'd check if PKI-IPA is running or if it is listening there. Relevant logs are in: /var/log/dirsrv/slapd-PKI-IPA/errors Example of `ipactl restart`: Shutting down dirsrv: DOM-189-ABC-IDM-LAB-ENG-BRQ-REDHAT-COM... [ OK ] PKI-IPA... [ OK ] Starting dirsrv: DOM-189-ABC-IDM-LAB-ENG-BRQ-REDHAT-COM... [ OK ] PKI-IPA... [ OK ] Restarting KDC Service Stopping Kerberos 5 KDC: [ OK ] Starting Kerberos 5 KDC: [ OK ] Restarting KPASSWD Service Stopping Kerberos 5 Admin Server: [ OK ] Starting Kerberos 5 Admin Server: [ OK ] Restarting DNS Service Stopping named: . [ OK ] Starting named:[ OK ] Restarting MEMCACHE Service Stopping ipa_memcached:[ OK ] Starting ipa_memcached:[ OK ] Restarting HTTP Service Stopping httpd:[ OK ] Starting httpd:[ OK ] Restarting CA Service [ OK ] Starting pki-ca: [ OK ] -- Petr Vobornik -- 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-replica-install failing, dirsrv not starting properly during install process
e >>>> [1/43]: creating directory server user >>>> [2/43]: creating directory server instance >>>> [3/43]: restarting directory server >>>> [4/43]: adding default schema >>>> [5/43]: enabling memberof plugin >>>> [6/43]: enabling winsync plugin >>>> [7/43]: configuring replication version plugin >>>> [8/43]: enabling IPA enrollment plugin >>>> [9/43]: enabling ldapi >>>> [10/43]: configuring uniqueness plugin >>>> [11/43]: configuring uuid plugin >>>> [12/43]: configuring modrdn plugin >>>> [13/43]: configuring DNS plugin >>>> [14/43]: enabling entryUSN plugin >>>> [15/43]: configuring lockout plugin >>>> [16/43]: configuring topology plugin >>>> [17/43]: creating indices >>>> [18/43]: enabling referential integrity plugin >>>> [19/43]: configuring certmap.conf >>>> [20/43]: configure autobind for root >>>> [21/43]: configure new location for managed entries >>>> [22/43]: configure dirsrv ccache >>>> [23/43]: enabling SASL mapping fallback >>>> [24/43]: restarting directory server >>>> [25/43]: creating DS keytab >>>> [26/43]: retrieving DS Certificate >>>> [27/43]: restarting directory server >>>> ipa : CRITICAL Failed to restart the directory server (Command >>>> '/bin/systemctl restart dirsrv@SOMETHING-BE.service' returned non-zero >>>> exit >>>> status 1). See the installation log for details. >>>> [28/43]: setting up initial replication >>>> [error] error: [Errno 111] Connection refused >>>> Your system may be partly configured. >>>> Run /usr/sbin/ipa-server-install --uninstall to clean up. >>>> >>>> >>>> [29/Nov/2016:11:29:44.034285579 +0100] SSL alert: Security >>>> Initialization: >>>> Can't find certificate (Server-Cert) for family >>>> cn=RSA,cn=encryption,cn=config (Netscape Portable Runtime error -8174 - >>>> security library: bad database.) >>>> [29/Nov/2016:11:29:44.045039728 +0100] SSL alert: Security >>>> Initialization: >>>> Unable to retrieve private key for cert Server-Cert of family >>>> cn=RSA,cn=encryption,cn=config (Netscape Portable Runtime error -8174 - >>>> security library: bad database.) >>>> >>>> >>>> >>>> >>> Hello David, >>> >>> The error from the log indicates that either the NSSDB for dirsrv is not >>> initialized or not accessible. >>> >>> Could you please send output of the following commands? >>> >>> # ls -lZ /etc/dirsrv/slapd-$REALM/ >>> # certutil -d /etc/dirsrv/slapd-$REALM/ -L >>> # ausearch -m avc -i >>> >>> >>> -- >>> David Kupka >>> -- Petr Vobornik -- 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] OTP Algorithm
On 11/28/2016 01:03 PM, Callum Guy wrote: > Hi All, > > I wanted to ask a quick question - perhaps a more experienced user will be > able > to help or point me to the correct documentation. > > Basically we have implemented password+OTP type authentication which works > great. > > When adding a OTP code using the admin login you can choose an algorithm. For > us > the generated codes only work properly if the weakest sha1 algorithm is > chosen/ > To be clear the code generation works fine but the codes are not valid when > logging in. Is there a related setting we must change? > > Thanks, > > Callum > What type of otp token do you use? Does it work with some different? E.g. FreeOTP vs Google Authenticator ... -- Petr Vobornik -- 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] How to verify user with proxy server
On 11/15/2016 09:38 AM, 郑磊 wrote: > Thanks for your reply. I may not have described clearly. My use case is that > I > have a freeipa user that uses password auth type by default, and I want to > use > radius auth tpye to verify user according to 3rd-party radius server. FreeIPA is able to use 3rd-pardy RADIUS server for authentication. This is covered in: * https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/otp.html#migrating-proprietary-otp * http://www.freeipa.org/page/V4/OTP > > > > > > -- > 祝： > 工作顺利！生活愉快！ > -- > 长沙研发中心 郑磊 > 电话：18684703229 > 邮箱：zheng...@kylinos.cn > 公司：天津麒麟信息技术有限公司 > 地址：湖南长沙市开福区三一大道工美大厦十四楼 > ------ Original -- > *From: * "Petr Vobornik"<pvobo...@redhat.com>; > *Date: * Mon, Nov 14, 2016 07:08 PM > *To: * "郑磊"<zheng...@kylinos.cn>; "freeipa-users"<freeipa-users@redhat.com>; > *Subject: * Re: [Freeipa-users] How to verify user with proxy server > On 11/14/2016 04:09 AM, 郑磊 wrote: > > Hello everyone, > > > > I had already successfully verified user with otp. But I don't know how to > > verify user with proxy server, is there anyone know about it? There is no a > > complete solution on the website. > > > > Thanks! > > > > Could you describe your use case in more details? > > If you are asking about how to access IPA behind proxy, then checkout: >https://www.adelton.com/freeipa/freeipa-behind-proxy-with-different-name > https://www.adelton.com/freeipa/freeipa-behind-ssl-proxy > > Or other proxy threads on this list. > -- > Petr Vobornik > -- Petr Vobornik -- 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] How to verify user with proxy server
On 11/14/2016 04:09 AM, 郑磊 wrote: > Hello everyone, > > I had already successfully verified user with otp. But I don't know how to > verify user with proxy server, is there anyone know about it? There is no a > complete solution on the website. > > Thanks! > Could you describe your use case in more details? If you are asking about how to access IPA behind proxy, then checkout: https://www.adelton.com/freeipa/freeipa-behind-proxy-with-different-name https://www.adelton.com/freeipa/freeipa-behind-ssl-proxy Or other proxy threads on this list. -- Petr Vobornik -- 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 UI not accessible behind the load blancer
On 11/14/2016 07:52 AM, deepak dimri wrote:
> Hi All,
>
>
> I have my IPA servers hosted in the AWS private subnets and i can access them
> using AWS elastic load balancer(elb) URL from public internet just fine. The
> problem is that when i enter https:///index.htl (dummy index.html
> hosted
> on IPA) i can access index.html just fine but when i try
> https:///ipa/ui then i am getting redirected to
> [https:///ipa/ui]https:///ipa/ui
> which is resulting to "This site can't be reached" error.
>
>
> I followed this link
> https://www.adelton.com/freeipa/freeipa-behind-proxy-with-different-name but
> it
> did not help either..
>
>
> What should i be doing to access IPA server(s) uri when they running behind
> the
> load balancer or proxy servers?
>
>
> Thanks for your great support!
>
>
> Best regards
>
> Deepak
>
Look into /etc/httpd/conf.d/ipa-rewrite.conf
There are lines:
# By default forward all requests to /ipa. If you don't want IPA
# to be the default on your web server comment this line out.
${AUTOREDIR}RewriteRule ^/$$ https://$FQDN/ipa/ui [L,NC,R=301]
# Redirect to the fully-qualified hostname. Not redirecting to secure
# port so configuration files can be retrieved without requiring SSL.
RewriteCond %{HTTP_HOST}!^$FQDN$$ [NC]
RewriteRule ^/ipa/(.*) http://$FQDN/ipa/$$1 [L,R=301]
Which most likely causes the redirection.
--
Petr Vobornik
--
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] guidance and strategies for supporting production use including dev/test IPA systems?
On 11/09/2016 02:39 PM, Chris Dagdigian wrote: > > Thanks to support from folks on this list I have a 3-node multi-site > replicating FreeIPA system supporting a number of 1-way trusts to > various AD Forests. Testing has gone well and it's clear that this "POC" > will soon transition to production. > > Because of the importance of this system to our environment I'm trying > to flesh out a proper strategy for testing upgrades and updates in a way > that lets us keep our system highly available and online. > > And seeing how rapidly this software is being developed w/ new features > and how dependent we are on the most recent version (or how badly I want > to try the version in RHEL-BETA-3) I think this is a system we will > possibly be upgrading somewhat often ... > > I understand that replicas can run newer versions of IPA/IDM than the > master so that is one path by which we can carefully test updates and > patches but I don't think that covers all the scenarios ... But be careful how much you want to test using this method. Setting up a new replica in prod environment should not be used as a playground. Usually new version of IPA modify some existing data in LDAP - schema change, add of some value here and there to support new features. Since IPA use master-master replication then all these changes are replicated to all other replicas(the older ones). It is fine because the changes are backwards compatible but they cannot be undone by removing the new replica. > > Can anyone share strategies or war stories for how testing is done in > support of production IPA/IDM environments? Especially when Trusts need > to be set up with many external AD systems? > > Do people run discrete standalone dev/test IPA domains/realms to create > isolated environments or is there some other good strategy that allows > testing to be done within the same domain/realm? > > Thanks! > > -Chris > -- Petr Vobornik -- 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] Package naming conflicts with update to RHEL 7.3
On 11/09/2016 12:43 PM, Prasun Gera wrote: > Thanks Martin. That bug report is private. Fixed, it's public now. > I take it that it's not very serious ? Should not affect IPA functionality. > > On Mon, Nov 7, 2016 at 3:12 AM, Martin Babinsky <mbabi...@redhat.com > <mailto:mbabi...@redhat.com>> wrote: > > On 11/07/2016 01:31 AM, Prasun Gera wrote: > > Getting this in yum check all after update to 7.3 > > ipa-client-4.4.0-12.el7.x86_64 has installed conflicts freeipa-client: > ipa-client-4.4.0-12.el7.x86_64 > ipa-client-common-4.4.0-12.el7.noarch has installed conflicts > freeipa-client-common: ipa-client-common-4.4.0-12.el7.noarch > ipa-common-4.4.0-12.el7.noarch has installed conflicts freeipa-common: > ipa-common-4.4.0-12.el7.noarch > ipa-python-compat-4.4.0-12.el7.noarch has installed conflicts > freeipa-python-compat: ipa-python-compat-4.4.0-12.el7.noarch > > > > > Hi Prasun, > > That is a false positive caused by a bug in yum, see > https://bugzilla.redhat.com/show_bug.cgi?id=1370134 > <https://bugzilla.redhat.com/show_bug.cgi?id=1370134> > > -- > Martin^3 Babinsky > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > <https://www.redhat.com/mailman/listinfo/freeipa-users> > Go to http://freeipa.org for more info on the project > > > > -- Petr Vobornik -- 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] IDM server doesn't boot after update to RHEL 7.3
On 11/09/2016 12:53 PM, Prasun Gera wrote: > It looks like something is messed up in the systemd configuration after 7.3. > My > system doesn't boot at all. The boot screen would display the message: > "Failed > to register match for Disconnected message: Connection timed out". After some > trial and error, I've managed to boot it. Here's what works right now: 1) > Boot > into system rescue target with debug shell 2) start sssd 3) isolate > graphical.target > > I have a replica which I haven't upgraded to 7.3 yet. So I can compare the > two > systems to isolate the problem. > I'm afraid that without more info(messages/journal) nobody will be able to help. But based on the description it seems that it didn't even get to step where IPA is started. -- Petr Vobornik -- 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] Setting sssd for webui
On 11/04/2016 03:09 PM, Sebastien Julliot wrote: > Hello everyone, > > As I explained you some time ago, I have been skirting the ipa's > limitation to setting pre-hashed passwords by using ldappasswd. (I know > you guys think it's wrong. In this case the hashes come from an other > ldap which, for intern reasons, we can not synchronize with otherwise > than by frequent ldif extractions. So it's the only solution to have > unified passwords) > > To have the kerberos key generated, I can ask the users to do an > ldapsearch or to ssh on a machine with sssd enabled. > Yet, as most users will mainly want to use the WebUi, I am looking for a > way to have them able to connect to it without needing to do an > ldapsearch first. > > To be precise, I set the userPassword field using ldappasswd, and delete > the krbprincipalkey. > > Do you see any way to make the webui directly authenticable ? > > Thanks, > Sebastien Julliot. > Not sure what you want exactly. But if you want users to do simple ldap bind with username and password and nothing else then they can use migration page: https://ipa.demo1.freeipa.org/ipa/migration/index.html -- Petr Vobornik -- 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] mkhomedir difference between ipa master and ipa replica
On 11/04/2016 02:42 PM, Brian Candler wrote:
> On 04/11/2016 12:20, Petr Vobornik wrote:
>> You can check with what options authconfig was called by:
>> # cat /var/log/ipaclient-install.log | grep authconfig
>>
>> if --enablemkhomedir is not there then it is possible that something
>> else enabled it.
>
> It's not there:
>
> $ sudo cat /var/log/ipaclient-install.log | grep authconfig
> [sudo] password for brian.candler:
> 2016-10-27T15:30:44Z DEBUG args='/usr/sbin/authconfig'
> '--enablesssdauth' '--update' '--enablesssd'
> 2016-10-27T15:30:44Z DEBUG args='/usr/sbin/authconfig' '--update'
> '--nisdomain' 'ipa.example.com'
>
> And:
>
> $ sudo cat /var/log/ipaclient-install.log | grep mkhome
> 2016-10-27T15:30:38Z DEBUG /usr/sbin/ipa-client-install was invoked with
> options: {'domain': 'ipa.example.com', 'force': False,
> 'krb5_offline_passwords': True, 'ip_addresses': [], 'configure_firefox':
> False, 'primary': False, 'realm_name': 'IPA.EXAMPLE.COM', 'force_ntpd':
> False, 'create_sshfp': True, 'conf_sshd': True, 'conf_ntp': True,
> 'on_master': True, 'no_nisdomain': False, 'nisdomain': None,
> 'ca_cert_file': None, 'principal': None, 'keytab': None, 'hostname':
> 'ipa-1.int.example.com', 'request_cert': False, 'trust_sshfp': False,
> 'no_ac': False, 'unattended': True, 'all_ip_addresses': False,
> 'location': None, 'sssd': True, 'ntp_servers': None, 'kinit_attempts':
> 5, 'dns_updates': False, 'conf_sudo': True, 'conf_ssh': True,
> 'force_join': False, 'firefox_dir': None, 'server':
> ['ipa-1.int.example.com'], 'prompt_password': False, 'permit': False,
> 'debug': False, 'preserve_sssd': False, 'mkhomedir': False, 'uninstall':
> False}
>
> This server has been through several iterations of ipa-server-install /
> ipa-server-uninstall. It is possible that one of the earlier
> incantations was done with --mkhomedir, since I didn't do the first one.
>
> Next time I do a fresh, clean IPA install I will check the PAM
> configuration.
> (Although in that case, perhaps ipa-server-uninstall is
> not cleaning up fully after itself?)
That may be possible.
>
> Regards,
>
> Brian.
>
--
Petr Vobornik
--
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] mkhomedir difference between ipa master and ipa replica
On 11/04/2016 12:52 PM, Brian Candler wrote: > On 04/11/2016 11:32, Brian Candler wrote: >> >> I notice that both ipa-server-install and ipa-replica-install have the >> following option: >> >> --mkhomedir create home directories for users on their first >> login >> >> but I did not supply this option in either case. I believe the actual >> options >> I gave were: >> >> ipa-server-install --setup-dns >> ipa-replica-install --setup-ca --setup-dns --forwarder x.x.x.x >> /var/lib/ipa/replica-info-*.gpg >> >> respectively. Is this expected behaviour, or should I raise a ticket? >> > Supplementary note for the benefit of the list: I tried manually updating the > replica machines' PAM configurations to match, but I then got this error > > org.freedesktop.DBus.Error.ServiceUnknown: The name > com.redhat.oddjob_mkhomedir > was not provided by any .service files > Last login: Fri Nov 4 11:36:07 2016 from x.x.x.x > Could not chdir to home directory /home/brian.candler: No such file or > directory > > All the machines had the same packages installed, including the > "oddjob-mkhomedir" package. But the slaves were missing a single symlink. > Solution was: > > ln -s /usr/lib/systemd/system/oddjobd.service > /etc/systemd/system/multi-user.target.wants/oddjobd.service > > Regards, > > Brian. > Both server and replica should pass this option to client installer which is executed as a part of server or replica installation. Before filing bugs, it would be good to check what/if something happened. Client installer configures creation of home dir in standard way. Meaning it calls something like: # authconfig --enablemkhomedir --update You can check with what options authconfig was called by: # cat /var/log/ipaclient-install.log | grep authconfig if --enablemkhomedir is not there then it is possible that something else enabled it. -- Petr Vobornik -- 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] Setting "preserve" as default action when deleting in webUI
On 10/21/2016 02:13 PM, Sébastien Julliot wrote: > Hi everyone, > > > In order to prevent administrators to make mistakes that could have > > silly consequences, I would like to set "preserve" as the default selected > > action in freeipa's webui. > > What do you think would be the best way to achieve this ? 1. Quick, more work: Create Web UI plugin which would change the hardcoded default to the other value: related code: https://git.fedorahosted.org/cgit/freeipa.git/tree/install/ui/src/freeipa/user.js#n989 example plugins: https://pvoborni.fedorapeople.org/plugins/ plugin info: https://pvoborni.fedorapeople.org/doc/#!/guide/Plugins 2. Uncertain delivery: File a ticket to change default or make it configurable(IMO better). Let core team to implement it. But note that there is quite a big number of other tickets which we prioritize. https://fedorahosted.org/freeipa/newticket 3. Do #2 and contribute patch for it. When reviewed, it would then go to currently developed version(4.5). This might be more work then #1. 4. dirty: change the default directly in Web UI code. Doesn't work well with upgrades, not supported, hard to find it in minimized code. > > > Thank you in advance, > > Sebastien Julliot. > -- Petr Vobornik -- 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] cn=deleted users,cn=accounts
On 10/27/2016 02:45 PM, Michael Ströder wrote: > Michael Ströder wrote: >> I wonder which action in the FreeIPA Web UI (4.2.0) moves an active user to >> this container: >> >> cn=deleted users,cn=accounts,cn=provisioning,dc=example,dc=com >> >> Selecting [Delete] as action really deletes the LDAP entry. > > Ah, found it myself: > It makes a difference choosing action [Delete] when displaying a single user > entry or from the user overview table. The latter asks whether to preserve the > entry or not. > > Is this UI inconsistency fixed in a later release? Yes, it has been fixed in 4.4 release. > > Ciao, Michael. > -- Petr Vobornik -- 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
[Freeipa-users] Announcing FreeIPA 4.4.2
tian Heimes (1) === * Use RSA-OAEP instead of RSA PKCS#1 v1.5 === David Kupka (2) === * UnsafeIPAddress: Implement __(g|s)etstate__ and to ensure proper (un)pickling * schema cache: Store and check info for pre-schema servers === Florence Blanc-Renaud (2) === * Fix regression introduced in ipa-certupdate * Fix ipa-certupdate for CA-less installation === Fraser Tweedale (10) === * Add commentary about CA deletion to plugin doc * spec: require Dogtag >= 10.3.5-6 * cert-request: raise error when request fails * Make host/service cert revocation aware of lightweight CAs * cert-request: raise CertificateOperationError if CA disabled * Use Dogtag REST API for certificate requests * Add HTTPRequestError class * Allow Dogtag RestClient to perform requests without logging in * Add ca-disable and ca-enable commands * Track lightweight CAs on replica installation === Jan Cholasta (8) === * test_plugable: update the rest of test_init * dns: re-introduce --raw in dnsrecord-del * client: remove hard dependency on pam_krb5 * cert: fix cert-find --certificate when the cert is not in LDAP * dns: fix crash in interactive mode against old servers * dns: prompt for missing record parts in CLI * dns: normalize record type read interactively in dnsrecord_add * cli: use full name when executing a command === Lenka Doudova (11) === * Tests: Certificate revocation * Tests: Remove invalid certplugin tests * Tests: Remove usage of krb5 ccache from test_ipaserver/test_ldap * Tests: Fix host attributes in ipa-join host test * Tests: Update host test with ipa-join * Tests: Add krb5kdc.service restart to integration trust tests * Tests: Remove SSSD restart from integration tests * Tests: Fix integration sudo tests setup and checks * Tests: Fix failing ldap.backend test * Tests: Add cleanup to integration trust tests * Tests: Fix regex errors in integration trust tests === Martin Babinsky (13) === * disable warnings reported by pylint-1.6.4-1 * mod_nss: use more robust quoting of NSSNickname directive * Move character escaping function to ipautil * Make Continuous installer continuous only during execution phase * use separate exception handlers for executors and validators * ipa passwd: use correct normalizer for user principals * trust-fetch-domains: contact forest DCs when fetching trust domain info * netgroup: avoid extraneous LDAP search when retrieving primary key from DN * ldapupdate: Use proper inheritance in BadSyntax exception * raise ValidationError when deprecated param is passed to command * Always fetch forest info from root DCs when establishing one-way trust * factor out `populate_remote_domain` method into module-level function * Always fetch forest info from root DCs when establishing two-way trust === Martin Basti (17) === * test_text: add test ipa.pot file for tests * Test: dont use global variable for iteration in test_cert_plugin * Use constant for user and group patterns * Fix regexp patterns in parameters to not enforce length * Add check for IP addresses into DNS installer * Fix missing config.ips in promote_check * Abstract procedures for IP address warnings * Catch DNS exceptions during emptyzones named.conf upgrade * Start named during configuration upgrade. * Tests: extend DNS cmdline tests with lowercased record type * Show warning when net/broadcast IP address is used in installer * Allow multicast addresses in A/ records * Allow broadcast ip addresses * Allow network ip addresses * Fix parse errors with link-local addresses * Fix ScriptError to always return string from __str__ * Set zanata project-version fo 4.4 branch === Milan Kubík (3) === * ipatests: Implement tests with CSRs requesting SAN * ipatests: Fix name property on a service tracker * ipatests: provide context manager for keytab usage in RPC tests === Nathaniel McCallum (1) === * Properly handle LDAP socket closures in ipa-otpd === Oleg Fayans (4) === * Test: disabled wrong client domain tests for domlevel 0 * Changed addressing to the client hosts to be replicas * Several fixes in replica_promotion tests * Removed incorrect check for returncode === Petr Spacek (1) === * Fix compatibility with python-dns 1.15.0 === Pavel Vomacka (5) === * WebUI: hide buttons in certificate widget according to acl * Add 'Restore' option to action dropdown menu * WebUI add support for sub-CAs while revoking certificates * WebUI: Fix showing certificates issued by sub-CA * Add support for additional options taken from table facet === Stanislav Laznicka (5) === * Make installer quit more nicely on external CA installation * Fix test_util.test_assert_deepequal test * Pretty-print structures in assert_deepequal * Remove update_from_dict() method * Updated help/man information about hostname === Tomas Krizek (4) === * Keep NSS trust flags of existing certificates * Update ipa-server-install man page for hostname * Add help info about certificate revocation reasons * Don't show error messages in bash completion -- Petr Vobornik -- Manage your su
Re: [Freeipa-users] replica added, but clients still try renewing certificates with old master
On 09/21/2016 05:06 PM, Natxo Asenjo wrote: > hi Petr, > > On Wed, Sep 21, 2016 at 4:38 PM, Petr Vobornik <pvobo...@redhat.com > <mailto:pvobo...@redhat.com>> wrote: > > On 09/21/2016 10:50 AM, Natxo Asenjo wrote: > > > When I try to resubmit certificates from certmonger they still hit the > kdc01 web > > server, so the requests hang on an status: CA_UNREACHABLE > > ca-error: Server failed request, will retry: 4301 (RPC failed at > server. > > Certificate operation cannot be completed: Failure decoding Certificate > Signing > > Request). > > Where does it happen? On arbitrary client which was installed in a past > against the removed kdc01? > > > yes. > > > If so could you look into /etc/ipa/default.conf and change host option > from kdc01 to the 7.2 IPA sever? > > > ok, done. > > In fact, change both the domain as the xmlrpc_uri directives in the global > section was necessary. Now It worked :-) > > So, what should be the correct value for dns discovery for both directives > using > dns discovery? I don't think there is a support for DNS discovery in Certmonger. CCing Rob. > > thanks! > -- > Groeten, > natxo > -- Petr Vobornik -- 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] down master still in ldap, prevents re-enrolement
On 09/21/2016 11:25 PM, pgb205 wrote: > topology prior to deletion > > master1<->master2 > > master2 deleted with ipa-server --uninstall command > > During re-installation I get error that the replication agreement still > exists > on master1. > I do see this using ipa-replica-manage list. > > Tried deleting replication agreement with > ipa-replica-manage disconnect but receive 'no such replication agreement > exist' > > Force deletion and cleanup do not work > receive unexpected error: Server is unwilling to perform: database is > read-only > > > removing directly from ldap gives me: > ldapdelete -r -x -D "cn=Directory Manager" -W > 'cn=fqdn,cn=masters,cn=ipa,cn=etc,dc=domain,dc=com' > Enter LDAP Password: > ldap_delete: Server is unwilling to perform (53) > ldap_delete: Server is unwilling to perform (53) > additional info: database is read-only > > But I am not sure if I'm not using correct path or if it's something else. > > Might be related to Bug 826677 – IPA cannot remove disconnected replica data > to > reconnect <https://bugzilla.redhat.com/show_bug.cgi?id=826677> > > > > > Bug 826677 – IPA cannot remove disconnected replica data to reconnect > > > > <https://bugzilla.redhat.com/show_bug.cgi?id=826677> > run on master1: ipa-csreplica-manage del master2 --force --clean ipa-replica-manage del master2 --force --clean In that order. First step only if master2 was installed with CA. Those command should clean left-over data from master2. In standard situation, recommended uninstallation procedure for IPAs prior FreeIPA 4.4 is: master1# ipa-csreplica-manage del master2 master1# ipa-replica-manage del master2 master2# ipa-server-install --uninstall -- Petr Vobornik -- 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] replica added, but clients still try renewing certificates with old master
On 09/21/2016 10:50 AM, Natxo Asenjo wrote: > hi, > > I followed the instructions here: > https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/upgrading.html > > and now after some issues I have a replica with both pki and dns data running > centos 7. > > So now I have 3 replicas: > > centos 6.8: > kdc01.unix.iriszorg.nl <http://kdc01.unix.iriszorg.nl> > kdc02.unix.iriszorg.nl <http://kdc02.unix.iriszorg.nl> > > centos 7.2 > kdc03.unix.iriszorg.nl <http://kdc03.unix.iriszorg.nl> > > The replica was created with an agreement to kdc01.unix.iriszorg.nl > <http://kdc01.unix.iriszorg.nl> which was the master for crl updates. I > followed > the steps to disabled crlcache and crlupdates on the kdc01 and to enable them > on > the kdc03. > > So in the kdc01 I edited /etc/httpd/conf.d/ipa-pki-proxy.conf and uncommented > > # Only enable this on servers that are not generating a CRL > RewriteRule ^/ipa/crl/MasterCRL.bin > https://kdc03.unix.iriszorg.nl/ca/ee/ca/getCRL?op=getCRL=MasterCRL > > [L,R=301,NC] > > and on the kdc03 i commented this out: > > # Only enable this on servers that are not generating a CRL > #RewriteRule ^/ipa/crl/MasterCRL.bin > https://kdc03.unix.iriszorg.nl/ca/ee/ca/getCRL?op=getCRL=MasterCRL > > [L,R=301,NC] > > > When I try to resubmit certificates from certmonger they still hit the kdc01 > web > server, so the requests hang on an status: CA_UNREACHABLE > ca-error: Server failed request, will retry: 4301 (RPC failed at server. > > Certificate operation cannot be completed: Failure decoding Certificate > Signing > Request). Where does it happen? On arbitrary client which was installed in a past against the removed kdc01? If so could you look into /etc/ipa/default.conf and change host option from kdc01 to the 7.2 IPA sever? If this is correct then IMO it is quite a serious bug which needs to be fixed (i.e. DNS discovery needs to be used). > > > Which was the problem on a recent thread on the list (trying to get rid of > this > replica now to fix this problem as well). > > So something is not redirecting properly and I would appreciate your > assistance. > > TIA. > -- > Groeten, > natxo > -- Petr Vobornik -- 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] CA: Cannot add Centos7.2 replica to Centos6.8 ipa server
On 09/14/2016 07:26 PM, Giorgos Kafataridis wrote: > > > On 09/13/2016 10:36 PM, Endi Sukma Dewata wrote: >> On 9/12/2016 9:35 PM, Endi Sukma Dewata wrote: >>> On 9/9/2016 2:46 PM, Georgios Kafataridis wrote: I've tried that but still the same result. [root@ipa-server /]# ldapsearch -D "cn=directory manager" -W -p 389 -h localhost -b "uid=admin,ou=people,o=ipaca" Enter LDAP Password: # extended LDIF # # LDAPv3 # base
Re: [Freeipa-users] ipa-server-certinstall -w -d mysite.key mysite.crt
On 09/15/2016 12:42 PM, Günther J. Niederwimmer wrote: > Hello, > > FreeIPA 4.3.1 > > is it a workaround to install the key and cert > > with this command I have to insert a password, but the key file have no > password? > > Afterward I have a Error from ipa-server-certinstall ? > > Thanks for the Help > Looks to me as bug: https://fedorahosted.org/freeipa/ticket/6032 It was fixed in FreeIPA 4.4.1 (will be in Fedora 25) -- Petr Vobornik -- 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] how to revert ipa-adtrust-install...
On 09/16/2016 01:51 PM, lejeczek wrote: > I appreciate the fact that it might be a complex task, however a > supported(CLI) way to if not revert it all back to pre-install state but > at least to take samba out of IPA's hands would be nice to have. > Would it be ok to leave IPA+ds389 part as is and only change, > reconfigure Samba - I believe so - if yes then a CLI option to achieve > this would be very desired. > Rob's workaround only... "built-in". Out of curiosity: is there a partial broader use case behind this feature request? > > many thanks > > On 16/09/16 05:57, Alexander Bokovoy wrote: >> So we decided to not perform 'ipa-adtrust-install --uninstall' as it >> makes no sense. If somebode is willing to uninstall >> 'ipa-adtrust-install', then need to realize what they are doing as it >> would need to remove certain configuration in IPA LDAP because there are >> actual 389-ds plugins that depend on the configuration and work jointly >> with ipasam module in Samba to provide common setup. If 'ipasam' is >> missing, those modules also become useless. > -- Petr Vobornik -- 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] certificates not renewing CA_UNREACHEABLE
On 09/16/2016 04:22 PM, Rob Crittenden wrote: > Natxo Asenjo wrote: >> hi, >> >> >> On Fri, Sep 16, 2016 at 10:34 AM, Martin Basti <mba...@redhat.com >> <mailto:mba...@redhat.com>> wrote: >> >> >> >> On 16.09.2016 09:38, Natxo Asenjo wrote: >>> hi, >>> >>> >>> On Thu, Sep 15, 2016 at 1:03 PM, Natxo Asenjo >>> <natxo.asenjo@gmail.c <mailto:natxo.ase...@gmail.com> >>> >>> On Thu, Sep 15, 2016 at 12:49 PM, Martin Basti >>> <mba...@redhat.com <mailto:mba...@redhat.com>> wrote: >>> >>> >>> >>> On 15.09.2016 12:44, Natxo Asenjo wrote: >>>> hi, >>>> >>>> On Thu, Sep 15, 2016 at 12:33 PM, Martin Basti >>>> <mba...@redhat.com <mailto:mba...@redhat.com>> wrote: >>>> >>>> >>>> Hello, >>>> >>>> usually the most information can be found here >>>> /var/log/pki/pki-tomcat/ca/debug >>>> >>>> >>>> mmm, in this centos 6.8 system that does not exist: >>>> >>>> # ls -l /var/log/pki/pki-tomcat/ca/debug >>>> ls: cannot access /var/log/pki/pki-tomcat/ca/debug: No >>>> such file or directory >>>> >>>> >>>> I do have a /var/log/pki-ca/debug >>>> >>>> >>> Does it contain any information related to your issue? >>> >>> >>> I have tried renewing the certificate: >>> >>> ipa-getcert resubmit -i 20121107212513 >>> >>> >>> If I grep that file for that request id I find nothing recent, >>> just in the ipaserver installation log >>> >>> # cd /var/log >>> # grep -ri 20121107212513 *.log >>> ipaserver-install.log:2012-11-07T21:25:13Z DEBUG stdout=New >>> tracking request "20121107212513" added. >>> >>> # grep -ri 20121107212513 pki-ca >>> # >>> >>> >>> Any clues? >>> >>> >>> -- >>> Groeten, >>> natxo >> >> >> Sorry, I'm quite lost here, maybe somebody from dogtag can help what >> might be reason of those CA errors >> >> >> >> do I need to ask in the dogtag list? > > You won't find any errors on this in the dogtag logs because it isn't > getting that far. > > The 3 certs you list are the ones that are renewed via the IPA API (as > opposed to the subsystem certs renewed directly by dogtag). I think the > failures are all related. I had someone else report the CSR decoding > failure and he just restarted IPA and that fixes things for him though > it was a rather unsatisfying fix. > > What I'd do is this. Assuming each step works, move onto the next. > > 1. ipa cert-show 1 > > The serial # picked more or less at random, we're testing connectivity > and that the CA is up and operational. > > 2. I assume that getcert list | grep expire shows all certs currently > valid? The IPA service certs expire in a month, how about the CA > subsystem certs? > > 3. Is this the same server having problems talking to the CA due to the > other NSS errors? If so what I'd do is restart httpd then immediately > use ipa-getcert to resubmit the requests to try to get into that few > minute window. The error log from thread [Freeipa-users] ipa: ERROR: Certificate format error: (SEC_ERROR_LEGACY_DATABASE) The certificate/key database is in an old, unsupported format." looks like it. > > If this is the same box you already have debugging enabled so seeing > what that shows might be helpful. > > rob > -- Petr Vobornik -- 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: ERROR: Certificate format error: (SEC_ERROR_LEGACY_DATABASE) The certificate/key database is in an old, unsupported format.
On 09/16/2016 09:39 AM, Natxo Asenjo wrote: > hi, > > > Any clues? > output of $ cat error_log | grep INFO -A 1 | cut -c -120 shows that first cert-show was successful. It was followed by cert-request. cert-request internally called - host-show - cert_show(1) success - cert_show(162) success - ipaserver.plugins.dogtag.ra.get_certificate() https_request 'https://xx.xxx.xxx.xx:443/ca/agent/ca/displayBySerial' - cert_revoke(162, recvocation_reason=4) - cert_show(162) success - cert_show(1) - success - ipaserver.plugins.dogtag.ra.revoke_certificate() - https_request 'https://xx.xxx.xxx.xx:443/ca/agent/ca/doRevoke' ends with: NetworkError [Thu Sep 15 13:08:23 2016] [error] ipa: DEBUG: response: NetworkError: cannot connect to 'https://xx.xxx.xxx.xx:443/ca/agent/ca/doRevoke': (SEC_ERROR_BUSY) NSS could not shutdown. Objects are still in use. After it every other communication with CA ends with the issue in subject: cert_show(u'15'): NetworkError [Thu Sep 15 13:08:26 2016] [error] ipa: DEBUG: response: NetworkError: cannot connect to 'https://xx.xxx.xxx.xxl:443/ca/agent/ca/displayBySerial': (SEC_ERROR_LEGACY_DATABASE) The certificate/key database is in an old, unsupported format. So the main issue is "NSS could not shutdown." Investigation of that is beyond me. Maybe a workaround can be do first revoke existing cert for the host and then request a new one - which might trigger a different sequence of calls and hopefully not reproduce the issue. But the issue will be still present. -- Petr Vobornik -- 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] CA: Cannot add Centos7.2 replica to Centos6.8 ipa server
On 09/09/2016 12:13 PM, Giorgos Kafataridis wrote:
> Yes, I have followed
> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/upgrading.html
>
> to the letter.
> The only reason I had to recreate the cacert.p12 file is because it is not
> renewed automatically in v3, so the cacert.p12 was outdated and the CA was
> throwing an "p12 invalid digest" error.
>
> * I opened all necessary ports
> * I checked all certs and they are valid for another year
>
>
> /Run connection check to master//
> //Check connection from replica to remote master 'ipa-server.nelios'://
> // Directory Service: Unsecure port (389): OK//
> // Directory Service: Secure port (636): OK//
> // Kerberos KDC: TCP (88): OK//
> // Kerberos Kpasswd: TCP (464): OK//
> // HTTP Server: Unsecure port (80): OK//
> // HTTP Server: Secure port (443): OK//
> // PKI-CA: Directory Service port (7389): OK//
> //
> //The following list of ports use UDP protocol and would need to be//
> //checked manually://
> // Kerberos KDC: UDP (88): SKIPPED//
> // Kerberos Kpasswd: UDP (464): SKIPPED//
> //
> //Connection from replica to master is OK.//
> //Start listening on required ports for remote master check//
> //Get credentials to log in to remote master//
> //Check SSH connection to remote master//
> //Execute check on remote master//
> //Check connection from master to remote replica 'ipa2-server2.nelios'://
> // Directory Service: Unsecure port (389): OK//
> // Directory Service: Secure port (636): OK//
> // Kerberos KDC: TCP (88): OK//
> // Kerberos KDC: UDP (88): OK//
> // Kerberos Kpasswd: TCP (464): OK//
> // Kerberos Kpasswd: UDP (464): OK//
> // HTTP Server: Unsecure port (80): OK//
> // HTTP Server: Secure port (443): OK//
> //
> //Connection from master to replica is OK.//
> //
> //Connection check OK/
>
> *Even with a fresh install of centos 7 with different hostname and ip and I
> still get the the error below*
>
> Configuring certificate server (pki-tomcatd). Estimated time: 3 minutes 30
> seconds
>[1/24]: creating certificate server user
>[2/24]: configuring certificate server instance
> ipa.ipaserver.install.cainstance.CAInstance: CRITICAL Failed to configure CA
> instance: Command ''/usr/sbin/pkispawn' '-s' 'CA' '-f' '/tmp/tmpbMwmp_''
> returned non-zero exit status 1
> ipa.ipaserver.install.cainstance.CAInstance: CRITICAL See the installation
> logs
> and the following files/directories for more information:
> ipa.ipaserver.install.cainstance.CAInstance: CRITICAL
> /var/log/pki-ca-install.log
> ipa.ipaserver.install.cainstance.CAInstance: CRITICAL /var/log/pki/pki-tomcat
>[error] RuntimeError: CA configuration failed.
> Your system may be partly configured.
> Run /usr/sbin/ipa-server-install --uninstall to clean up.
>
> ipa.ipapython.install.cli.install_tool(Replica): ERRORCA configuration
> failed.
>
> *
> **With debug enabled I get: *
>
> pa : DEBUGStarting external process
> ipa : DEBUGargs='/usr/sbin/pkispawn' '-s' 'CA' '-f'
> '/tmp/tmpwY8XjR'
> ipa : DEBUGProcess finished, return code=1
> ipa : DEBUGstdout=Log file:
> /var/log/pki/pki-ca-spawn.20160909044214.log
> Loading deployment configuration from /tmp/tmpwY8XjR.
> Installing CA into /var/lib/pki/pki-tomcat.
> Storing deployment configuration into
> /etc/sysconfig/pki/tomcat/pki-tomcat/ca/deployment.cfg.
>
> Installation failed.
>
>
> ipa : DEBUG
> stderr=/usr/lib/python2.7/site-packages/urllib3/connectionpool.py:769:
> InsecureRequestWarning: Unverified HTTPS request is being made. Adding
> certificate verification is strongly advised. See:
> https://urllib3.readthedocs.org/en/latest/security.html
>InsecureRequestWarning)
> pkispawn: WARNING ... unable to validate security domain
> user/password
> through REST interface. Interface not available
> pkispawn: ERROR... Exception from Java Configuration Servlet: 500
> Server Error: Internal Server Error
> pkispawn: ERROR... ParseError: not well-formed (invalid token):
> line
> 1, column 0:
> {"Attributes":{"Attribute":[]},"ClassName":"com.netscape.certsrv.base.PKIException","Code":500,"Message":"Failed
>
> to obtain installation token from security domain"}
>
>
> Is there a way to validate the repilca .gpg file from a v3 installation
> against
> a v4.2 freeipa installation to check for any errors before going through the
> ipa-replica-install?
> The ipa-replica-inst
Re: [Freeipa-users] Ansible Playbook
On 08/16/2016 03:43 PM, Deepak Dimri wrote: > Hi All, > > I am looking to write ansible playbook to automatically register my EC2 > instances as freeIPA clients to my IPA Server and then add the client(s) to a > particular hostgroup based on EC2 tag value. For example EC2 tag key value= > prod > will add the client to prod hostgroup. I am wondering if there is any freeIPA > client module available for this purpose already that i can leverage? > > Many Thanks, > Deepak > Some Ansible recipes were developed by Christian for testing/demoing of FreeIPA or Dogtag PKI: https://github.com/tiran/pki-vagans Might be helpful. -- Petr Vobornik -- 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] freeipa 4.4 online repo is down
On 08/08/2016 09:36 AM, Martin Basti wrote: > > > On 08.08.2016 09:14, Lukas Slebodnik wrote: >> On (08/08/16 09:06), Ben .T.George wrote: >>> Hi List, >>> >>> always https://copr.fedorainfracloud.org/ is down, is there any >>> alternative >>> repo were i can get IPA 4.4? >>> >> Your link does not point to any specific repo? >> Which copr reposiory did you mean? >> >> LS >> > IIRC we haven't released 4.4 in any repo. > > Martin > Right, FreeIPA 4.4 contained a bigger number of regressions, especially in CLI, that it was not even announced. The FreeIPA team is working on stabilization which will result in FreeIPA 4.4.1. That release will most-likely be available for Fedora 25 and also probably in a COPR repository for testing on CentOS 7. -- Petr Vobornik -- 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] Querying the dir srv
On 08/04/2016 06:43 PM, Sean Hogan wrote: > Thanks Ben.. appreciated.. will give it a go. Do you guys recommend any > specific > ldap viewer to view the internals? I was looking at apache dir studio I think > it > was... but needs java and I don't want to add java > to a server that does not have it increasing the mitigation/vulnerability > factor > of the box. > > I ran ipa host-find --all > and noticed this setting in the list > Keytab: True > > I am thinking Keytab entry = enroll true That is correct. Entrolled == true in Web UI means has_keytab in CLI which means that the host object has krbprincipalkey LDAP attribute set. > > Sean Hogan > > > > > Inactive hide details for Ben Lipton ---08/04/2016 09:08:40 AM---On > 08/04/2016 > 11:31 AM, Sean Hogan wrote: >Ben Lipton ---08/04/2016 09:08:40 AM---On > 08/04/2016 11:31 AM, Sean Hogan wrote: > > > From: Ben Lipton <blip...@redhat.com> > To: Sean Hogan/Durham/IBM@IBMUS, freeipa-users <freeipa-users@redhat.com> > Date: 08/04/2016 09:08 AM > Subject: Re: [Freeipa-users] Querying the dir srv > > > > > > On 08/04/2016 11:31 AM, Sean Hogan wrote: > > > > Hi All, > > > > Where can I find information about the IPA schema as in what = what in > > the dir srv? I do not have a ldap viewer. > > I am looking to pull specific info from it such as a list of servers > > that have enrolled = true and have been playing with ldapsearch to no > > avail. > > > > You could try something like 'ipa -show --all ' to > see the dn of the associated LDAP object for a particular IPA entity. > This would give you a sense of what tree to ldapsearch. You could try > adding the --raw flag as well to see the LDAP attributes of the object. > > # ipa user-show --all admin >dn: uid=admin,cn=users,cn=accounts,dc=example,dc=domain > [...] > # ldapsearch -xLLL -D cn='Directory manager' -w > -b 'cn=users,cn=accounts,dc=example,dc=domain' '(objectClass=*)' '*' | > perl -p0e 's/\n //g' | less > > You can also take a look at > https://git.fedorahosted.org/cgit/freeipa.git/tree/ipalib/constants.py#n78 > for a list of LDAP entities that act as containers for IPA objects > (subtrees to search under). > > Someone else may have some better ideas, but maybe this can get you started. > > Ben > > > > > > -- Petr Vobornik -- 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] Deleted Replica Problems
On 08/03/2016 08:06 PM, Ian Harding wrote: > I deleted a replica that had a corrupted ldap database and it caused > some problems. I'm now getting the dreaded What do you mean by "deleted"? Ran `ipa-replica-mange del $server`? Removed the machine completely? Or something else? > > [root@edinburghnfs ianh]# ipa-replica-manage connect freeipa-sea.bpt.rocks > Connection unsuccessful: freeipa-sea.bpt.rocks is an IPA Server, but it > might be unknown, foreign or previously deleted one. > > I had to go around and remove old replication agreements from the other > replicas, but then they could connect again. This one, and another, I > am not able to do that with. They were initially created with > freeipa-sea as their master. Which replica is the deleted one? freeipa-sea.bpt.rocks or edinburghnfs ? > > I assume I run ipa-server-install --uninstall on edinburghnis, then > reinstall to fix? > > There's always an error about having to "Manually remove" the ldap > database. What's the best way to do that? Where is the error shown and what is the exact text? In general - if replica is removed/uninstall then it cannot be added back - incorrectly removed repliacase might - have still dangling replication agreements - various ldap entries in LDAP db which are normally removed by `ipa-replica-manage del $replica` - suffer from dangling ruvs Most of the issues above can be fixed by `ipa-(cs)replica-manage del $replica --clean --force commands`. And then clean ruvs commands of the same tool. Correct order of IPA replica is: - transfer CA CRL and CA renewal roles to different replica if this one is the master which handles it - make sure you have other relica with CA - run `ipa-csreplica-manage del $tobedeleted` on different replica - run `ipa-replica-manage del $tobedeleted` on different replica - run `ipa-server-install --uninstall` on the to-be-delete-replica -- Petr Vobornik -- 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] Client is using only one of two servers
On 08/04/2016 11:48 AM, Keller, Mario wrote: > Hello, > > I've setup two ipa-servers on RHEL 7 that are up an running. Replication is > also working. > > #ipa-replica-manage list > Directory Manager password: > > s-fcbg-ipa2.ipa.cornelsen.de: master > s-onli-ipa1.ipa.cornelsen.de: master > > Both servers running ipa-server-4.2 : > > rpm -qa | grep ipa-server > ipa-server-dns-4.2.0-15.el7_2.17.x86_64 > ipa-server-4.2.0-15.el7_2.17.x86_64 > > I have also a client installed running also version 4.2 > > ipa-client-4.2.0-15.el7_2.17.x86_64 > > The client and the first server are in the same subnet, while server 2 is in > a different subnet. > All ports that are required are open for server 1 to server 2 and also for > the client to server two. > > I have an subdomain ipa.cornelsen.de that is managed by both ipa-servers. the > subdomain is forwarded by out general dns-server to both ipa-servers. > > If I switch server 1 off I would expect that the client is using the second > server to check access and sudo rights, but that's not the case. If I create > a new user on the ipa-server and then switch off the first server, the user > cannot login to the client. If I switch on server 1 again, the user can > login. > > The official documentation says: > > " There can be multiple servers and replicas within the IdM server topology. > When a client needs to connect to a server for updates or to retrieve user > information, it (by default) uses a service scan to discover available > servers and replicas in the domain. This means that the actual server to > which the client connects is random, depending on the results of the > discovery scan." > > But there's no information how this scan is done. > > I have to provide the server and the domain during the client installation. > But regarding to the documentation, the server can by any server or replica > in my topology. This server is saved also in the > /etc/ipa/default.conf > > How is the service scan working and is there a way to manually check what the > service-check is returning? > > With best regards, > > Mario Keller > IT-Operations Engineer > Hello, With what options were the clients installed? Autodiscovery works only if the client is installed also with autodiscover. That means that if ipa-client-install is run with --server option then autodiscovery is not used. This is documented in ipa-client-install man page. HTH -- Petr Vobornik -- 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-server-install --external-cert-file and exporting dogtag certificates
On 07/31/2016 07:45 AM, Richard Harmonson wrote: > I having challenges resuming ipa-server-install --external-ca. I am > reasonably > confident I am not providing the right certificate and/or format from my > off-line root CA using 389 and Dogtag. > > Does anyone have instructions on how to accomplish the task of exporting the > correct certificates in the expected format? > > Thank you. > The IPA procedure with prerequisites is described at https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/install-server.html#install-server-external-ca Or are you rather asking for specific PKI instructions? e.g. * http://pki.fedoraproject.org/wiki/PKI_Certificate_CLI#Submitting_a_Certificate_Request * http://pki.fedoraproject.org/wiki/CA_Certificate_Profiles#caCACert:_Manual_Certificate_Manager_Signing_Certificate_Enrollment -- Petr Vobornik -- 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
[Freeipa-users] Announcing FreeIPA 4.3.2
_test: Rename exception instance before working with it * radiusproxy plugin: Use str(error) rather than error.message * xmlrpc_test: Expect bytes rather than strings for binary attributes * ipalib.rpc: Send base64-encoded data as string under Python 3 * range plugin tests: Use bytes with MockLDAP under Python 3 * radiusproxy plugin tests: Expect bytes, not text, for ipatokenradiussecret * certprofile plugin: Use binary mode for file with binary data * test_add_remove_cert_cmd: Use bytes for base64.b64encode() * Switch /usr/bin/ipa to Python 3 * Fix remaining relative import and enable Pylint check * ipalib.cli: Improve reporting of binary values in the CLI * test_cert_plugin: Encode 'certificate' for comparison with 'usercertificate' * ipaldap: Keep attribute names as text, not bytes * ipapython.secrets.kem: Use ConfigParser from six.moves * test_topology_plugin: Don't rely on order of an attribute's values * test_rpcserver: Expect updated error message under Python 3 * ipaplatform.redhat: Use bytestrings when calling rpm.so for version comparison * test_ipaserver.test_ldap: Use bytestrings for raw LDAP values * ipaldap: Convert dict items to list before iterating * test_ipaserver.test_ldap: Adjust tests to Python 3's KeyView === Petr Voborník (2) === * mod_auth_gssapi: enable unique credential caches names * Become IPA 4.3.2 === Petr Špaček (30) === * Remove function ipapython.ipautil.host_exists() * Extend installers with --forward-policy option * Move automatic empty zone list into ipapython.dnsutil and make it reusable * Add assert_absolute_dnsname() helper to ipapython.dnsutil * Move function is_auto_empty_zone() into ipapython.dnsutil * Use shared sanity check and tests ipapython.dnsutil.is_auto_empty_zone() * Add function ipapython.dnsutil.inside_auto_empty_zone() * Auto-detect default value for --forward-policy option in installers * DNS: Fix upgrade - master to forward zone transformation * DNS installer: accept --auto-forwarders option in unattended mode * Batch command: avoid accessing potentially undefined context.principal * Move check_zone_overlap() from ipapython.ipautil to ipapython.dnsutil * Use root_logger for verify_host_resolvable() * Move IP address resolution from ipaserver.install.installutils to ipapython.dnsutil * Turn verify_host_resolvable() into a wrapper around ipapython.dnsutil * Add ipaDNSVersion option to dnsconfig* commands and use new attribute * DNS upgrade: separate backup logic to make it reusable * Add function ipapython.dnsutil.related_to_auto_empty_zone() * DNS upgrade: change forwarding policy to = only for conflicting forward zones * DNS upgrade: change global forwarding policy in LDAP to "only" if private IPs are used * DNS upgrade: change global forwarding policy in named.conf to "only" if private IPs are used * DNS: Warn if forwarding policy conflicts with automatic empty zones * DNS: Fix realm domains integration with DNS zone add. * client: Share validator and domain name normalization with server install * DNS: Fix tests for realm domains integration with DNS zone add * client-install: do not fail if DNS times out during DNS update generation * Use NSS for name->resolution in IPA installer * DNS: Remove unnecessary DNS check from installer * Remove unused is_local(), interface, and defaultnet from CheckedIPAddress * Fix internal errors in host-add and other commands caused by DNS resolution === Stanislav Laznicka (9) === * replica-manage: fail nicely when DM psswd required * ipa-replica-manage refactoring * abort-clean/list/clean-ruv now work for both suffixes * Moved password check from clean_dangling_ruv * Fix to clean-dangling-ruv for single CA topologies * Added pyusb as a dependency * Deprecated the domain-level option in ipa-server-install * fixes premature sys.exit in ipa-replica-manage del * Remove dangling RUVs even if replicas are offline === Thierry Bordaz (1) === * Make sure ipapwd_extop takes precedence over passwd_modify_extop -- Petr Vobornik -- 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] Bypass pre-hashed passwords verification
On 07/22/2016 11:42 AM, Sébastien Julliot wrote:
> Hello everyone,
>
> I am currently trying to deploy FreeIPA as the new idm system in my
> university but came across a problem I could not solve yet. I need to
> bypass the pre-hashed passwords verification, not only on the user creation.
>
> Due to several constraints, our workflow involves periodically (once a
> day, currently) receiving an ldif file containing the users up-to-date
> informations, (including hashed passwords) and inserting this
> informations into the idm. As our goal is to unify users passwords in
> the university but do not have access to the higher-level LDAP directly,
> we injected this pre-hashed passwords directly into the LDAP until today.
>
> Yet, every attempt I made to update users passwords with pre-hashed
> passwords failed for now.
>
> First I tried this (migration mode enabled):
>
> ➜ ~ ipa user-add testuser --first=test --last=user --setattr
> userpassword='{MD5}*'
>
> /*OK*/
>
> ➜ ~ kinit testuser
>
> kinit: Generic preauthentication failure while getting initial credentials
>
> As expected from the documentation, it does not work :p
>
> I then thought about trying to copy the migration plug-in, and change
> the way it retrieves users (from LDIF rather than from an online LDAP
> server). Since this plugin is able to But again, event binding as
> Directory Manager, the ipa ldap2 backend method add_entry refuses me (I
> tested my code without the userPassword field and the users are
> correctly inserted).
>
> Here is my code :
>
> class ldif_importer(ldif.LDIFParser):
> def __init__(self, ldap_backend):
> ldif.LDIFParser.__init__(self, open('test.ldif', 'rb'))
> self.ldap = ldap_backend
>
> def handle(self, dn, entry):
> self.ldap.add_entry(self.ldap.make_entry(DN(dn), entry))
>
> class my_backend(ipalib.Backend):
> '''Backend to import ldap passwords from ldif'''
>
> def __init__(self, api):
> ipalib.Backend.__init__(self, api)
> self.ldap = ldap2(self.api)
> self.ldap.connect(bind_dn=DN('cn=Directory Manager'),
> bind_pw='***')
>
> def parse(self):
> importer = ldif_importer(self.ldap)
> importer.parse()
>
> class my_command(ipalib.Command):
> '''Command calling my_backend to import passwords from ldif'''
>
> def execute(self, **options):
> '''Implemented against my_backend'''
> self.Backend.my_backend.parse()
> return {'result': 'everything OK'}
>
>
> Should one of these methods have worked, and I did it incorrectly ?
> Otherwise, what would be the lower-impact solution to achieve this ?
> (Yes, I understand the security concerns about sending passwords hashes
> on the network but this choice does not depend on me)
>
> Many thanks in advance,
> Sebastien.
>
I issue might be that the user has his userPassword migrated but he
doesn't have krbPrincipalKey generated. If kerberos key is missing then
it is automatically generated on successful LDAP bind (it's what
ipa/migration page does)
Additional info which might interest you:
*
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Windows_Integration_Guide/pass-sync.html#password-sync
* http://www.freeipa.org/page/NIS_accounts_migration_preserving_Passwords
--
Petr Vobornik
--
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 certificates expired, please help!
; self test plugin called selftests.container.instance.SystemCertsVerification > running at startup FAILED! > > But intrestingly, [root@caer ~]# ipa cert-show 1 returns "*ipa: ERROR: > Certificate operation cannot be completed: Unable to communicate with CMS > (Not > Found)*" > > On Thu, Jul 21, 2016 at 10:04 AM, Linov Suresh <linov.sur...@gmail.com > <mailto:linov.sur...@gmail.com>> wrote: > > This could be because of incorrect trust attributes trust on the > certificates, the current attributes are, > > [root@caer ~]# certutil -L -d /var/lib/pki-ca/alias > > Certificate Nickname Trust > Attributes > > SSL,S/MIME,JAR/XPI > > ocspSigningCert cert-pki-ca u,u,Pu > subsystemCert cert-pki-ca u,u,Pu > caSigningCert cert-pki-ca CTu,Cu,Cu > subsystemCert cert-pki-ca u,u,Pu > Server-Cert cert-pki-ca u,u,u > auditSigningCert cert-pki-ca u,u,Pu > > I'm going to fix the trust attributes and try. > > On Thu, Jul 21, 2016 at 9:45 AM, Petr Vobornik <pvobo...@redhat.com > <mailto:pvobo...@redhat.com>> wrote: > > On 07/20/2016 09:41 PM, Linov Suresh wrote: > > I have restarted the pki-cad and checked if communication with the > CA is > > working, but no luck, > > > > Debug logs in /var/log/pki-ca do not have anything unusual. Can you > think of > > anything other than this? > > /var/log/httpd/error_log when /etc/ipa.conf is set to debug=true > > https://www.freeipa.org/page/Troubleshooting#ipa_command_crashes_or_returns_no_data > > /var/log/pki-ca/debug > /var/log/pki-ca/transactions > /var/log/pki-ca/selftest.log > > > > > [root@caer ~]# ipa cert-show 1 > >Certificate: > MIIDizCCAnOgAwIBAgIBATANBgkqhkiG9w0BAQsFADA1MRMwEQYDVQQKEwpURUxP > > SVAuTkVUMR4wHAYDVQQDExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNMTExMjE0 > > MjIyOTU2WhcNMTkxMjE0MjIyOTU2WjA1MRMwEQYDVQQKEwpURUxPSVAuTkVUMR4w > > HAYDVQQDExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwggEiMA0GCSqGSIb3DQEBAQUA > > A4IBDwAwggEKAoIBAQDegJ5XVR0JSc76s9FPkkkuug3PtZi5Ysad0Dr1I5ngjTOV > > ctm/P7buk2g8LxBSXLO+7Rq7PTtTD5AJ7vQjrv2RtoYTPdRebAuukTKd6RhtYa5e > > tX7z0DBjQ8g9Erqf9GzLxlQqim8ZvscATBhf6MLb5cXA/pWHYuE2j0OlnrSNWqsb > > UgwMsM73RlsNACsvLUk4iJY0wuxj4L/0EBQWUPGr8qBk3QBST4LDnInuvvGsAFNe > > tyebENMRWnEaDFYKPapACrtKAl3hQNDB7dVGk64Dd7paXss9F8vgVnofgFpjiJs7 > > 5DNtKhKxzFQyanINU+uuIVs/CNIO3jV9I26ems2zAgMBAAGjgaUwgaIwHwYDVR0j > > BBgwFoAUx5/ZpwOfXZQ5KNwC42cBW+Y+bGIwDwYDVR0TAQH/BAUwAwEB/zAOBgNV > > HQ8BAf8EBAMCAcYwHQYDVR0OBBYEFMef2acDn12UOSjcAuNnAVvmPmxiMD8GCCsG > > AQUFBwEBBDMwMTAvBggrBgEFBQcwAYYjaHR0cDovL2NhZXIudGVsb2lwLm5ldDo5 > > MTgwL2NhL29jc3AwDQYJKoZIhvcNAQELBQADggEBAHGElN0OcepokvNIN8f4mvTj > > kL9wcuZwbbX9gZGdKSZf5Redp4tsJW8EJCy8yu9F5U+Ym3RcvJBiby9gHCVVbW+y > > 5IgziiJ3kd4UlVJCDVKtbdq62bODcatFsMH8wJSMW6Cw096RyfGgu2qSyXzdZ2xV > > nMovO3+Eaz2n0x4ZvaEj9Ixym/KI+QPCAL7gPkK36X4JYgM3CXUCYCN/QJY/psFt > > e+121ubSZX5u3Yntux4KziJ3cx9wZ74iKff1BOVxOCi0JyLn2k15bvBXGvxxgmhK > > b8YUVbDJDb9oWSbixl/TQI9PZysXYIvBNJM8h+HRKIJksKGQhKOERzrYoqABt30= > >Subject: CN=Certificate Authority,O=TELOIP.NET > <http://TELOIP.NET> > <http://TELOIP.NET> > >Issuer: CN=Certificate Authority,O=TELOIP.NET > <http://TELOIP.NET> > <http://TELOIP.NET> > >Not Before: Wed Dec 14 22:29:56 2011 UTC > >Not After: Sat Dec 14 22:29:56 2019 UTC > >Fingerprint (MD5): > c9:27:1d:84:4c:2c:97:38:a4:7b:9a:c0:78:3e:7f:7a > >Fingerprint (SHA1): > ce:d7:11:84:70:dd:cb:4e:e2:08:f5:c0:ac:ff:b3:c5:bb:81:77:7e > >Serial number (hex): 0x1 > >Serial number: 1 > > [root@caer ~]# > > > > *ca-error: Internal error: no response to > > > > "http://caer.teloip.net:9180/ca/ee/ca/profileSubmit?profileId=caServerCert_num=63=true=true;. > > * > > > > > > > > On Wed, Jul 20, 2016 at 2:22 PM, Rob Crittenden > <rcrit...@redhat.com <mailto:rcrit...
Re: [Freeipa-users] IPA certificates expired, please help!
uto-renew: yes > >On Mon, Jul 18, 2016 at 12:00 PM, Linov > Suresh ><linov.sur...@gmail.com > <mailto:linov.sur...@gmail.com> > <mailto:linov.sur...@gmail.com > <mailto:linov.sur...@gmail.com>> > <mailto:linov.sur...@gmail.com <mailto:linov.sur...@gmail.com> > <mailto:linov.sur...@gmail.com > <mailto:linov.sur...@gmail.com>>> > <mailto:linov.sur...@gmail.com > <mailto:linov.sur...@gmail.com> > <mailto:linov.sur...@gmail.com > <mailto:linov.sur...@gmail.com>> > <mailto:linov.sur...@gmail.com <mailto:linov.sur...@gmail.com> > <mailto:linov.sur...@gmail.com > <mailto:linov.sur...@gmail.com>>>>> > wrote: > >Yes, PKI is running and I don't see any > errors in > selftests, >I have followed > https://access.redhat.com/solutions/643753 >and restarted the PKI in step 10. > >The only change which I made was clean >up userCertificate;binary before > adding new >userCertificatein LDAP, which is step > 12. > > >[root@caer ~]# /etc/init.d/pki-cad > status >pki-ca (pid 8634) is running... >[ > OK ] > Unsecure Port = > http://caer.teloip.net:9180/ca/ee/ca > Secure Agent Port = > https://caer.teloip.net:9443/ca/agent/ca > Secure EE Port = > https://caer.teloip.net:9444/ca/ee/ca > Secure Admin Port = > https://caer.teloip.net:9445/ca/services > EE Client Auth Port = > https://caer.teloip.net:9446/ca/eeca/ca > PKI Console Port= pkiconsole > https://caer.teloip.net:9445/ca > Tomcat Port = 9701 (for > shutdown) > > PKI Instance Name: pki-ca > > PKI Subsystem Type: Root CA > (Security Domain) > > Registered PKI Security Domain > Information: > > > > > > == > Name: IPA > URL: https://caer.teloip.net:9445 > > > > > > == >[root@caer ~]# >[root@caer ~]# tail -f > /var/log/pki-ca/selftests.log >8634.main - [18/Jul/2016:11:46:20 EDT] > [20] [1] >SelfTestSubsystem: loading all self > test > plugin logger > parameters >8634.main - [18/Jul/2016:11:46:20 EDT] > [20] [1] >SelfTestSubsystem: loading all self > test > plugin > instances >8634.main - [18/Jul/2016:11:46:20 EDT] > [20] [1] >SelfTestSubsystem: loading all self > test > plugin > instance >parameters >8634.main - [18/Jul/2016:11:46:20 EDT] > [20] [1] >SelfTestSubsystem: loading self test > plugins in > on-demand order >8634.main - [18/Jul/2016:11:46:20 EDT] > [20] [1] >SelfTestSubsystem: loading
Re: [Freeipa-users] IPA certificates expired, please help!
TC > eku: id-kp-OCSPSigning > pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad > post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert > "ocspSigningCert cert-pki-ca" > track: yes > auto-renew: yes > Request ID '20130519130743': > status: MONITORING > ca-error: Internal error: no response to > "http://caer.teloip.net:9180/ca/ee/ca/profileSubmit?profileId=caServerCert_num=62=true=true;. > stuck: no > key pair storage: > type=NSSDB,location='/var/lib/pki-ca/alias',nickname='subsystemCert > cert-pki-ca',token='NSS Certificate DB',pin='297100916664' > certificate: > type=NSSDB,location='/var/lib/pki-ca/alias',nickname='subsystemCert > cert-pki-ca',token='NSS Certificate DB' > CA: dogtag-ipa-renew-agent > issuer: CN=Certificate Authority,O=TELOIP.NET <http://TELOIP.NET> > subject: CN=CA Subsystem,O=TELOIP.NET <http://TELOIP.NET> > expires: 2017-10-13 14:09:49 UTC > eku: id-kp-serverAuth,id-kp-clientAuth > pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad > post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert > "subsystemCert cert-pki-ca" > track: yes > auto-renew: yes > Request ID '20130519130744': > status: MONITORING > ca-error: Internal error: no response to > "http://caer.teloip.net:9180/ca/ee/ca/profileSubmit?profileId=caServerCert_num=64=true=true;. > stuck: no > key pair storage: > type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS > Certificate > DB',pinfile='/etc/httpd/alias/pwdfile.txt' > certificate: > type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS > Certificate DB' > CA: dogtag-ipa-renew-agent > issuer: CN=Certificate Authority,O=TELOIP.NET <http://TELOIP.NET> > subject: CN=RA Subsystem,O=TELOIP.NET <http://TELOIP.NET> > expires: 2017-10-13 14:09:49 UTC > eku: id-kp-serverAuth,id-kp-clientAuth > pre-save command: > post-save command: /usr/lib64/ipa/certmonger/restart_httpd > track: yes > auto-renew: yes > Request ID '20130519130745': > status: MONITORING > ca-error: Internal error: no response to > "http://caer.teloip.net:9180/ca/ee/ca/profileSubmit?profileId=caServerCert_num=63=true=true;. > stuck: no > key pair storage: > type=NSSDB,location='/var/lib/pki-ca/alias',nickname='Server-Cert > cert-pki-ca',token='NSS Certificate DB',pin='297100916664' > certificate: > type=NSSDB,location='/var/lib/pki-ca/alias',nickname='Server-Cert > cert-pki-ca',token='NSS Certificate DB' > CA: dogtag-ipa-renew-agent > issuer: CN=Certificate Authority,O=TELOIP.NET <http://TELOIP.NET> > subject: CN=caer.teloip.net <http://caer.teloip.net>,O=TELOIP.NET > <http://TELOIP.NET> > expires: 2017-10-13 14:09:49 UTC > eku: id-kp-serverAuth,id-kp-clientAuth > pre-save command: > post-save command: /usr/lib64/ipa/certmonger/restart_dirsrv > "TELOIP.NET > <http://TELOIP.NET>" > track: yes > auto-renew: yes > [root@caer ~]# > > Your help is highly appreciated! > > > > On Fri, Jul 15, 2016 at 5:08 PM, Rob Crittenden <rcrit...@redhat.com > <mailto:rcrit...@redhat.com>> wrote: > > Linov Suresh wrote: > > I logged into my IPA master, and found that the cert had expired > again, > we renewed these certificates about 18 months ago. > > Our environment is CentOS 6.4 and IPA 3.0.0-26. > > >I followed the Redhat documentation,How do I manually renew > Identity >Management (IPA) certificates after they have expired? (Master IPA >Server), https://access.redhat.com/solutions/643753 but no luck. > > > I have also changed the directive "NSSEnforceValidCerts off" in > /etc/httpd/conf.d/nss.conf and the value of nsslapd-validate-cert is > warn. > > ldapsearch -x -h localhost -p 7389 -D 'cn=directory manager' -w > *** > -b cn=config | grep nsslapd-validate-cert > > nsslapd-validate-cert: warn > > Here is my getcert list, > > [root@caer ~]# getcert list > > > It looks like your CA subsystem certificates all renewed successfully it > is > just the webserver and LDAP certificates that need renewing so that's > good. > > What I'd do is go back in time again to say Jan 20, 2016 and restart > certmonger. That should make it retry the renewals. > > rob > > > > -- Petr Vobornik -- 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] Migrating to FreeIPA from an existing Heimdal Kerberos and 389-ds deployment
On 07/18/2016 03:57 PM, Rob Crittenden wrote: > Grant Wu wrote: >> Thanks for the information. Do you know if there are any plans to >> support cross-realm trust with general KDCs? > > https://fedorahosted.org/freeipa/ticket/4867 > > rob In general, IPA contains krb5 component which can be in theory configured to trust other krb5 KDC. But this procedure is manual. IPA doesn't provide any tooling to easy it and it is not tested therefore not supported. The general Kerberos realm trust is not planned for any upcoming release mostly because we don't see a big demand for it. Feel free to cc yourself or add comment to https://fedorahosted.org/freeipa/ticket/4917 It will raise the visible demand. Ticket 4867 is different, it is about IPA-IPA trusts where the scope is more confined. It may or may not(more probable) allow the trust with general KDC as a side effect. Demand for IPA-IPA trust is raising so it is definitively on our radar and has a chance to be implemented in some of upcoming releases. For completeness, there is also a RFE to support IPA-SAMBA 4 DC trusts: https://fedorahosted.org/freeipa/ticket/4866 -- Petr Vobornik -- 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] DNS Forwarding stops working
On 07/15/2016 12:49 PM, Marc Boorshtein wrote: > I've got a freeipa server using an AD server as a DNS forwarder. It > was working great until about an hour ago and now FreeIPA won't > forward any requests to the DNS server. using nslookup from the > server against ad works perfectly. Restarting services has not > worked. How can I debug this issue? Details: > > CentOS 7 - CentOS Linux release 7.2.1511 (Core) > IPA - ipa-server-4.2.0-15.0.1.el7.centos.17.x86_64 > > Thanks > > Marc Boorshtein > CTO Tremolo Security > marc.boorsht...@tremolosecurity.com > Twitter - @mlbiam / @tremolosecurity > I'd start with investigation of: # journalctl -u named-pkcs11 And with: # ipactl status -- Petr Vobornik -- 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] FreeIPA (Add Replica fails on GSSAPI)
On 07/14/2016 10:16 PM, Devin Acosta wrote: > When i tried to create the replica from another server, it fails giving me > this? > > [root@ipa02-aws ~]# ipa-replica-prepare ipa03-aws.rsinc.local --ip-address > 10.40.x.x > Directory Manager (existing master) password: > > If you installed IPA with your own certificates using PKCS#12 files you must > provide PKCS#12 files for any replicas you create as well. > The replica must be created on the primary IPA server. What is your topology? Does ipa02-aws have a CA (doesn't seem so)? Replica file can be created only on a replica with CA unless whole topo is install as CA less(then it needs other options). It is strongly encouraged to have more than one replica with CA. Was anything in directory server errors log on master? > > On Thu, Jul 14, 2016 at 8:22 AM, Petr Vobornik <pvobo...@redhat.com > <mailto:pvobo...@redhat.com>> wrote: > > On 07/14/2016 07:18 AM, Bjarne Blichfeldt wrote: > > Well, I just had the same problem, but in my case I also tried to > install a ca: > > > > “ipa-replica-install --setup-ca …..” > > > > Without “--set-up” the installation succeeded. > > > > Regards, > > > > Bjarne > > > > The error below is not related to CA. > > It tries to check that new replica's ldap service principal was replica > to master server. The principal is not replicated there and after 60 > attemps it fails. > > What is your replication topology? Could it be that other replicas are > keeping this master busy? > > Does installation against other replica work? > > Could you provide dirsrv error log of the master from the time of > installation? > > > > > > > *From:*Devin Acosta [mailto:linuxguru...@gmail.com > <mailto:linuxguru...@gmail.com>] > > *Sent:* 12. juli 2016 21:35 > > *To:* freeipa-users@redhat.com <mailto:freeipa-users@redhat.com> > > *Subject:* [Freeipa-users] FreeIPA (Add Replica fails on GSSAPI) > > > > I am trying to add a 4th replica to my FreeIPA installation. I am > running the > > latest CentOS 7.2 (full updates) and i have tried multiple times and > fails every > > time in same location. When it fails I remove the replication > agreements and try > > again and keeps failing in same location. > > > > [root@ipa03-aws centos]# ipa-replica-install > replica-info-ipa03-aws.rsinc.local.gpg > > > > WARNING: conflicting time synchronization service 'chronyd' will > > > > be disabled in favor of ntpd > > > > Directory Manager (existing master) password: > > > > Run connection check to master > > > > Check connection from replica to remote master 'ipa01-aws.rsinc.local': > > > > Directory Service: Unsecure port (389): OK > > > > Directory Service: Secure port (636): OK > > > > Kerberos KDC: TCP (88): OK > > > > Kerberos Kpasswd: TCP (464): OK > > > > HTTP Server: Unsecure port (80): OK > > > > HTTP Server: Secure port (443): OK > > > > The following list of ports use UDP protocol and would need to be > > > > checked manually: > > > > Kerberos KDC: UDP (88): SKIPPED > > > > Kerberos Kpasswd: UDP (464): SKIPPED > > > > Connection from replica to master is OK. > > > > Start listening on required ports for remote master check > > > > Get credentials to log in to remote master > > > > admin@RSINC.LOCAL <mailto:admin@RSINC.LOCAL <mailto:admin@RSINC.LOCAL>> > password: > > > > Check SSH connection to remote master > > > > Execute check on remote master > > > > Check connection from master to remote replica 'ipa03-aws.rsinc.local': > > > > Directory Service: Unsecure port (389): OK > > > > Directory Service: Secure port (636): OK > > > > Kerberos KDC: TCP (88): OK > > > > Kerberos KDC: UDP (88): OK > > > > Kerberos Kpasswd: TCP (464): OK > > > > Kerberos Kpasswd: UDP (464): OK > > > > HTTP Server: Unsecure port (80): OK > > > > HTTP Server: Secure port (443): OK > > > > Connection from master to repl
Re: [Freeipa-users] Replication Agreement issues noticed with repl-monitor.pl
On 07/15/2016 08:17 AM, Martin Kosek wrote: > You should be able to succeed with "ipa-replica-manage del " > and --force/--cleanup flags: but first call ipa-csreplica-manage del --force/--cleanup > > $ man ipa-replica-manage > ... >-c, --cleanup > When deleting a master with the --force flag, remove leftover > references to an already deleted master. > ... > > Martin > > On 07/14/2016 05:35 PM, Devin Acosta wrote: >> ipa01-jap was a host that is no more, is there a simple way to clear these >> replication agreements to clean it up? >> >> On Thu, Jul 14, 2016 at 7:14 AM, Petr Vobornik <pvobo...@redhat.com >> <mailto:pvobo...@redhat.com>> wrote: >> >> On 07/14/2016 12:57 PM, Martin Kosek wrote: >> > On 07/13/2016 04:24 AM, Devin Acosta wrote: >> >> >> >> I was trying to create another Replica but then noticed it was >> constantly having >> >> issues trying to finish the joining of the replication. I then ran >> the >> command: >> >> repl-monitor.pl <http://repl-monitor.pl> <http://repl-monitor.pl>, It >> appears i have several replicaid's >> >> and they seem to be having issues, wondering if this is adding to my >> issue. >> >> >> >> Anyone know how I can resolve this issue and clean up the >> replication??? >> >> >> >> See attached Screenshot. >> > >> > I wonder if cleaning RUVs help: >> > >> > >> >> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/trouble-replica.html#trouble-repl-cleanruv >> > >> >> dangling RUVs >> >> 1. "Can't acquire busy replica" >> seems OK if it disappears after a while. >> >> 2. "1 Unable to acquire replicaLDAP error: Can't contact LDAP" >> Probably worth investigating if ipa01- >> i2x.rsinc.local:389 and ipa01- >> jap.rsinc.local:389 still exist. If not then there is probably a >> dangling replication agreement for o=ipaca suffix. >> >> -- >> Petr Vobornik >> >> > -- Petr Vobornik -- 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] FreeIPA (Add Replica fails on GSSAPI)
from LDAP > >[29/38]: initializing group membership > >[30/38]: adding master entry > >[31/38]: initializing domain level > >[32/38]: configuring Posix uid/gid generation > >[33/38]: adding replication acis > >[34/38]: enabling compatibility plugin > >[35/38]: activating sidgen plugin > >[36/38]: activating extdom plugin > >[37/38]: tuning directory server > >[38/38]: configuring directory to start on boot > > Done configuring directory server (dirsrv). > > Configuring Kerberos KDC (krb5kdc). Estimated time: 30 seconds > >[1/8]: adding sasl mappings to the directory > >[2/8]: configuring KDC > >[3/8]: creating a keytab for the directory > >[4/8]: creating a keytab for the machine > >[5/8]: adding the password extension to the directory > >[6/8]: enable GSSAPI for replication > >[error] RuntimeError: One of the ldap service principals is missing. > Replication agreement cannot be converted. > > Replication error message: Can't acquire busy replica > > Your system may be partly configured. > > Run /usr/sbin/ipa-server-install --uninstall to clean up. > > ipa.ipapython.install.cli.install_tool(Replica): ERROROne of the ldap > service principals is missing. Replication agreement cannot be converted. > > Replication error message: Can't acquire busy replica > > Please see attached file for the full log file. > > Any help would be appreciated! > > > -- Petr Vobornik -- 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] named-pkcs11 fails on new ipa replica
store > > I've tried "ipa-server-upgrade" and > > mv /var/lib/ipa/dnssec/tokens /var/lib/ipa/dnssec/tokens-OLD > > ipa-dns-install > > But I haven't managed to fix it. > > Using "ipactl start -f" means the rest of the ipa services seem to work > properly, but without named. > > Is there a way to fix the named issue or is it much simpler to > disconnect the replica, uninstall it and start again ? > > Thanks > > Bob Hinton > Hi Bob, what is the version of you IPA packages? Do you use the latest update? Sounds like an issue which should be fixed in ipa-server-4.2.0-15.el7_2.5.x86_64 what is your umask settings? The issue happend when there was umask set to 077 and then the softhsm dir was created with incorrect permissions. -- Petr Vobornik -- 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] Migrating to FreeIPA from an existing Heimdal Kerberos and 389-ds deployment
On 07/14/2016 07:13 AM, Grant Wu wrote: > Hi all, > > I'm part of the CMU Computer Club and our Kerberos/LDAP deployment has been a > pain point for quite some time. I've heard that FreeIPA might be a solution > worth exploring. > > I would like to try to avoid user visible disruption if possible, however. > This > means that we would like to keep our Kerberos realm name, keep AFS > cross-realm > authentication working, etc. UIDs remaining the same would be good; I'd have > to > think about Users and groups can be migrated by `ipa migrate-ds` command. It allows you to keep UIDs and GIDs but one must make sure that IPA servers are configured to issue new UIDs and GIDs which doesn't overlap with the migrated ones. There are options in ipa-server-install and ipa-replica-manage tools for that. This can be evaluated in an isolated network against a clone of your LDAP server. Cross realm trust with AFS is a challenge though. IPA now supports only cross realm trust with Active Directory. Trusts with other general KDCs are not yet supported. Other migration challenge might be migration of services. It is not done by the above mentioned `ipa migrate-ds`. When the service accounts are added to IPA, you would have to obtain new keytabs for the services. > > Essentially all of our clients are various flavors of Debian; mostly Jessie > (we > have an unfortunate number of older machines that I hope to upgrade soon). A possibility is to use SSSD as client on Debian. > > Has anyone done something like this before? Anyone have any ideas what the > migration path would look like or whether this is even possible? > > Thanks, > > Grant Wu > gran...@andrew.cmu.edu <mailto:gran...@andrew.cmu.edu> > -- Petr Vobornik -- 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] Replication Agreement issues noticed with repl-monitor.pl
On 07/14/2016 12:57 PM, Martin Kosek wrote: > On 07/13/2016 04:24 AM, Devin Acosta wrote: >> >> I was trying to create another Replica but then noticed it was constantly >> having >> issues trying to finish the joining of the replication. I then ran the >> command: >> repl-monitor.pl <http://repl-monitor.pl>, It appears i have several >> replicaid's >> and they seem to be having issues, wondering if this is adding to my issue. >> >> Anyone know how I can resolve this issue and clean up the replication??? >> >> See attached Screenshot. > > I wonder if cleaning RUVs help: > > https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/trouble-replica.html#trouble-repl-cleanruv > dangling RUVs 1. "Can't acquire busy replica" seems OK if it disappears after a while. 2. "1 Unable to acquire replicaLDAP error: Can't contact LDAP" Probably worth investigating if ipa01- i2x.rsinc.local:389 and ipa01- jap.rsinc.local:389 still exist. If not then there is probably a dangling replication agreement for o=ipaca suffix. -- Petr Vobornik -- 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] Problem with properly removing replica master from cluster
On 07/04/2016 05:54 PM, Christophe TREFOIS wrote: Dear all, First of all, thanks to mbasti for helping out so far. We have a 3-node master cluster (—setup-ca) on 4.1 and setup a 4th using 4.2.0 as we want to migrate there. First, we had some orphan entries in ipa-replica-manage list. We removed those by manually removing the LDAP node + children in cn=etc,cn=ipa,cn=masters. Then, we saw that there is still an orphan entry here: ldapsearch -xLLL -D "cn=directory manager" -W -b dc=uni,dc=lu '(&(nsuniqueid=---)(objectclass=nstombstone))’ In particular, there is one ghost entry for nsDS5ReplicaBindDN This is the details of ldapsearch -x -D 'cn=directory manager' -W -b 'cn=Replication Manager masterAgreement1-lums3.uni.lu-pki-tomcat,ou=csusers,cn=config' Enter LDAP Password: # extended LDIF # # LDAPv3 # base
Re: [Freeipa-users] ipa-replica-prepare Certificate issuance failed
uld not store certificate serial number 0x3 At corresponding times, in the debug logs there are entries like: [01/Jul/2016:16:04:58][http-bio-8443-exec-4]: LDAP operation failure - cn=1,ou=certificateRepository, ou=ca, o=ipaca netscape.ldap.LDAPException: error result (68) [01/Jul/2016:16:04:58][http-bio-8443-exec-4]: CertRequestSubmitter: submit LDAP operation failure - cn=1,ou=certificateRepository, ou=ca, o=ipaca netscape.ldap.LDAPException: error result (68) [01/Jul/2016:16:04:58][http-bio-8443-exec-4]: SignedAuditEventFactory: create() message=[AuditEvent=CERT_REQUEST_PROCESSED][SubjectID=ipara][Outcome=Failure][ReqID=1][InfoName=rejectReason][InfoValue=Server Internal Error] certificate request processed And then in the dirsrv error file there seems to be one of these for each of the attempts to run ipa-replica-prepare: [01/Jul/2016:16:04:57 +0100] - Entry "uid=admin,ou=people,o=ipaca" -- attribute "krbExtraData" not allowed [01/Jul/2016:16:07:16 +0100] - Entry "uid=admin,ou=people,o=ipaca" -- attribute "krbExtraData" not allowed [01/Jul/2016:16:13:36 +0100] - Entry "uid=admin,ou=people,o=ipaca" -- attribute "krbExtraData" not allowed Do you think this is looking like the root cause? Can you suggest how we fix that? Thanks. Roderick Hi Did anyone have any ideas on fixing this please. I'm a bit stuck now. When you changed the DM passwords did you follow this, http://www.freeipa.org/page/Howto/Change_Directory_Manager_Password rob Hi Rob Well, yes, but I did nothing because I read that page to say that nothing needed doing becuase our server was on freeipa 4.2.0 (Redhat 7.2) and the procedure is automated for that version freeipa 3.3.2. Did I misunderstand that? Roderick Roderick, could you attach also snipped of dirsrv access log around the time you see the "attribute "krbExtraData" not allowed" error? After that, could you try to do step 3 of http://www.freeipa.org/page/Howto/Change_Directory_Manager_Password to check if the automatic password change which is done in ipa-replica-prepare failed. And if it is therefore the root cause. -- Petr Vobornik -- 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] how to make fIPA stick to only...
On 06/30/2016 04:56 PM, lejeczek wrote: > ... its own FQHN and its IP ? > > hi users, > > I'm fiddling with rewrites but being an amateur cannot figure it out, > it's on a multi/home-IP box. Is it possible? > > many thanks, > > L. > Hi L. Could you describe your environment and use case in more details. It is not clear to me what you are trying to achieve or what doesn't work for you. Thank you -- Petr Vobornik -- 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
[Freeipa-users] Announcing FreeIPA 4.4.0 alpha1
pautil.host_exists()
Extend installers with --forward-policy option
Move automatic empty zone list into ipapython.dnsutil and make it
reusable
Add assert_absolute_dnsname() helper to ipapython.dnsutil
Move function is_auto_empty_zone() into ipapython.dnsutil
Use shared sanity check and tests
ipapython.dnsutil.is_auto_empty_zone()
Add function ipapython.dnsutil.inside_auto_empty_zone()
Auto-detect default value for --forward-policy option in installers
ipa-nis-manage: Replace text references to compat plugin with NIS
ipa-nis-manage: mention return code 3 in man page
DNS: Fix upgrade - master to forward zone transformation
DNS installer: accept --auto-forwarders option in unattended mode
Remove unused file install/share/fedora-ds.init.patch
Batch command: avoid accessing potentially undefined context.principal
pylint: replace Refactor category with individual check names
ipa-nis-manage: add status option
DNS: Warn if forwarding policy conflicts with automatic empty zones
Move check_zone_overlap() from ipapython.ipautil to ipapython.dnsutil
Use root_logger for verify_host_resolvable()
Move IP address resolution from ipaserver.install.installutils to
ipapython.dnsutil
Turn verify_host_resolvable() into a wrapper around ipapython.dnsutil
Add ipaDNSVersion option to dnsconfig* commands and use new attribute
DNS upgrade: separate backup logic to make it reusable
Add function ipapython.dnsutil.related_to_auto_empty_zone()
DNS upgrade: change forwarding policy to = only for conflicting
forward zones
DNS upgrade: change global forwarding policy in LDAP to "only" if
private IPs are used
DNS upgrade: change global forwarding policy in named.conf to
"only" if private IPs are used
Require 389-ds-base >= 1.3.5.6
DNS Locations: make ipa-ca record generation more robust
DNS: Support default TTL setting for master DNS zones
DNS: Warn about restart when default TTL setting DNS is changed
DNS: Fix realm domains integration with DNS zone add.
Simo Sorce (6):
Use only AES enctypes by default
Always verify we have a valid ldap context.
Improve keytab code to select the right principal.
Convert ipa-sam to use the new getkeytab control
Allow admins to disable preauth for SPNs.
Allow to specify Kerberos authz data type per user
Stanislav Laznicka (21):
Listing and cleaning RUV extended for CA suffix
Automatically detect and remove dangling RUVs
Cosmetic changes to the code
Fixes minor issues
replica-manage: fail nicely when DM psswd required
ipa-replica-manage refactoring
abort-clean/list/clean-ruv now work for both suffixes
Moved password check from clean_dangling_ruv
Fix to clean-dangling-ruv for single CA topologies
Added pyusb as a dependency
Added some attributes to Modify Users permission
Deprecated the domain-level option in ipa-server-install
Increased mod_wsgi socket-timeout
Added = mapping to krb5.conf
Decreased timeout for IO blocking for DS
fixes premature sys.exit in ipa-replica-manage del
Remove dangling RUVs even if replicas are offline
Added krb5.conf.d/ to included dirs in krb5.conf
Removed dead code from LDAP{Remove,Add}ReverseMember
Fixes CA always being presented as running
Increase nsslapd-db-locks to 5
Sumit Bose (3):
ipa-kdb: get_authz_data_types() make sure entry can be NULL
ipa-kdb: map_groups() consider all results
extdom: add certificate request
Thierry Bordaz (3):
configure DNA plugin shared config entries to allow connection
with GSSAPI
DS deadlock when memberof scopes topology plugin updates
Make sure ipapwd_extop takes precedence over passwd_modify_extop
Thorsten Scherf (1):
Fixed typo in service-add
Timo Aaltonen (6):
Use HTTPD_USER in dogtaginstance.py
Move freeipa certmonger helpers to libexecdir.
ipa_restore: Import only FQDN from ipalib.constants
ipaplatform: Move remaining user/group constants to
ipaplatform.constants.
Use ODS_USER/ODS_GROUP in opendnssec_conf.template
Fix kdc.conf.template to use ipaplatform.paths.
Tomáš Babej (10):
py3: Remove py3 incompatible exception handling
logger: Use warning instead of warn
Loggger: Use warning instead of warn - dns plugin
ipa-getkeytab: Handle the possibility of not obtaining a result
ipa-adtrust-install: Allow dash in the NETBIOS name
spec: Bump required sssd version to 1.13.3-5
adtrustinstance: Make sure smb.conf exists
l10n: Remove Transifex configuration
ipalib: Fix user certificate docstrings
idviews: Add user certificate attribute to user ID overrides
Yuri Chornoivan (3):
Fix minor typo
Fix minor typos
Fix minor typos
Re: [Freeipa-users] Multiple issues (weblogin, DNS) with 4.3.1
-- > > > ad 3) cannot login to webui on okda > > When I go to https://okda.pipebreaker.pl/ipa/ui/ (the other server), I see > "Loading…" screen > for couple of seconds, and afterwards "Gateway timeout" message. Everything > seems to be running on this server: > > root@okda ~$ ipactl status > WARNING: yacc table file version is out of date > Directory Service: RUNNING > krb5kdc Service: RUNNING > kadmin Service: RUNNING > named Service: RUNNING > ipa_memcached Service: RUNNING > httpd Service: RUNNING > ipa-custodia Service: RUNNING > pki-tomcatd Service: RUNNING > ipa-otpd Service: RUNNING > ipa-dnskeysyncd Service: RUNNING > ipa: INFO: The ipactl command was successful > > There are no logs generated in httpd's error_log during login. > There are some problems in system log: > May 27 14:25:48 okda.pipebreaker.pl server[2364]: May 27, 2016 2:25:48 PM > org.apache.catalina.core.ContainerBase backgroundProcess > May 27 14:25:48 okda.pipebreaker.pl server[2364]: WARNING: Exception > processing realm com.netscape.cms.tomcat.ProxyRealm@5ad7c518 background > process > May 27 14:25:48 okda.pipebreaker.pl server[2364]: > java.lang.NullPointerException > May 27 14:25:48 okda.pipebreaker.pl server[2364]: at > com.netscape.cms.tomcat.ProxyRealm.backgroundProcess(ProxyRealm.java:109) > May 27 14:25:48 okda.pipebreaker.pl server[2364]: at > org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBase.java:1127) > May 27 14:25:48 okda.pipebreaker.pl server[2364]: at > org.apache.catalina.core.StandardContext.backgroundProcess(StandardContext.java:5642) > May 27 14:25:48 okda.pipebreaker.pl server[2364]: at > org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1377) > May 27 14:25:48 okda.pipebreaker.pl server[2364]: at > org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1381) > May 27 14:25:48 okda.pipebreaker.pl server[2364]: at > org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1381) > May 27 14:25:48 okda.pipebreaker.pl server[2364]: at > org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1349) > May 27 14:25:48 okda.pipebreaker.pl server[2364]: at > java.lang.Thread.run(Thread.java:745) > > as you can see, those logs do not contain any clue what's is wrong. Httpd error_log should at least show which operation encountered the Gateway timeout. If not, then put IPA framework into debug mode: http://www.freeipa.org/page/Troubleshooting#Administration_Framework Gateway timeout - some operation takes more than 30s, will be removed in 4.4 - https://fedorahosted.org/freeipa/ticket/5833. But still it won't make the operation quicker. > > - > > ad 4) pycparser.lextab/lextab.py/yacctab.py permission errors > I observe following errors in dnskeysyncd logs: > > May 27 14:08:29 kaitain.pipebreaker.pl ipa-dnskeysyncd[22469]: WARNING: > Couldn't write lextab module 'pycparser.lextab'. [Errno 13] Permission > denied: 'lextab.py' > May 27 14:08:29 kaitain.pipebreaker.pl ipa-dnskeysyncd[22469]: WARNING: yacc > table file version is out of date > May 27 14:08:29 kaitain.pipebreaker.pl ipa-dnskeysyncd[22469]: WARNING: > Couldn't create 'pycparser.yacctab'. [Errno 13] Permission denied: > 'yacctab.py' > > Also (related?) error during 'ipactl' invocations: > $ ipactl status > WARNING: yacc table file version is out of date > … > These were seen before, it is not known if it affect IPA functionality. https://bugzilla.redhat.com/show_bug.cgi?id=1336913 > Warnings appear even after switching SELinux to permissive. > > > Please help me with resolving those problems. What logs should I provide? > I see no similiar issues described at > http://www.freeipa.org/page/Troubleshooting > > -- Petr Vobornik -- 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] FreeIPA 4.2.0: An error has occurred (IPA Error 4301: CertificateOperationError)
gt; >at > > org.apache.catalina.core.ContainerBase.access$000(ContainerBase.java:133) > >at > > > org.apache.catalina.core.ContainerBase$PrivilegedAddChild.run(ContainerBase.java:156) > >at > > > org.apache.catalina.core.ContainerBase$PrivilegedAddChild.run(ContainerBase.java:145) > >at java.security.AccessController.doPrivileged(Native > > Method) > >at > > org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:875) > >at > > org.apache.catalina.core.StandardHost.addChild(StandardHost.java:632) > >at > > > org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:672) > >at > > > org.apache.catalina.startup.HostConfig$DeployDescriptor.run(HostConfig.java:1862) > >at > > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > >at > java.util.concurrent.FutureTask.run(FutureTask.java:262) > >at > > > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > >at > > > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > >at java.lang.Thread.run(Thread.java:745) > > I think we might be willing to toss out the existing certificate store > > and start anew, which fortunately should preserve the DNS, user, group, > > etc., data already in LDAP. If we wanted to create a new trust and > > self-signed cert for the server, how are those steps different from > > promoting a replica to a cert-signing master? > > Thanks, > > Dan > > /This message and any attachments may contain confidential or privileged > > information and are only for the use of the intended recipient of this > > message. If you are not the intended recipient, please notify the sender > > by return email, and delete or destroy this and all copies of this > > message and all attachments. Any unauthorized disclosure, use, > > distribution, or reproduction of this message or any attachments is > > prohibited and may be unlawful./ > > *From: *Rob Crittenden <rcrit...@redhat.com <mailto:rcrit...@redhat.com>> > > *Date: *Friday, June 10, 2016 at 14:48 > > *To: *Daniel Finkestein <dan.finkelst...@high5games.com > <mailto:dan.finkelst...@high5games.com>>, > > "freeipa-users@redhat.com <mailto:freeipa-users@redhat.com>" > <freeipa-users@redhat.com <mailto:freeipa-users@redhat.com>> > > *Subject: *Re: [Freeipa-users] FreeIPA 4.2.0: An error has occurred (IPA > > Error 4301: CertificateOperationError) > > I'd reinstall some rpms to properly create these: > > tomcat > > pki-base > > pki-server > > I'm not positive it will fix permissions, rpm -V on the same may point > > out problems as well. > > rob > > > -- Petr Vobornik -- 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] Replica without CA: implications?
On 06/08/2016 11:15 AM, Cal Sawyer wrote: > In /var/log/dirsrv/slapd-LOCALDOMAIN-LOCAL/errors on all IPA > master/replicas:, there's a multitude of these messages. There are no > other error messages and replication, from viewing access log, appears > to be working > > [08/Jun/2016:10:06:08 +0100] attrlist_replace - attr_replace > (nsslapd-referral, > ldap://ipa.localdomain.local:389/dc%3Dlocaldomain%2Cdc%3Dlocal) failed. > >> ipa-replica-manage list-ruv > > ipa.localdomain.local:389: 4 > ipa4.localdomain.local:389: 28 > ipa2.localdomain.local:389: 17 > ipa3.localdomain.local:389: 29 > ipa2.localdomain.local:389: 8 > > This is correct, yes? > > - c sawyer > one of(probably 8): ipa2.localdomain.local:389: 17 ipa2.localdomain.local:389: 8 is incorrect. https://www.freeipa.org/page/Troubleshooting#Obsolete_RUV_records You need to identify which one is INCORRECT and then run ipa-replica-manage clean-ruv $incorrect command. The CORRECT one can identified with: ldapsearch -ZZ -h ipa2.localdomain.local -D "cn=Directory Manager" -W -b "dc=localdomain,dc=local" "(&(objectclass=nstombstone)(nsUniqueId=---))" | grep "nsDS5ReplicaId" -- Petr Vobornik -- 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] [FreeIPA 4.3.0] Limits exceeded for this query
On 8.6.2016 10:45, Martin Kosek wrote: On 06/07/2016 09:08 PM, Nathan Peters wrote: I get this when doing almost anything on only one of my Fedora 23 FreeIPA 4.3.0 servers. The rest work fine. This server also tends to crash quite a bit and the others do not. Any tips on what I should be looking for or how to fix that ? Some operations failed. Hide details <https://dc1-ipa-dev-van.dev-globalrelay.net/ipa/ui/> ·limits exceeded for this query Nathan Peters CCing Petr. I wonder if this is related to https://fedorahosted.org/freeipa/ticket/5833 It is most likely something else. #5833 happens after 30s. Limits Exceeded error indicates that some query hit LDAP size or time limit. More info will be visible on the server in httpd/error_log and dirsrv/$instance/access log. We need to know: - which operation fails - does it internally query bigger number of data - what is the size and time limit configured -- Petr Vobornik -- 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] Unable to access to web ui
[26/May/2016:12:14:10 +0200] NSACLPlugin - The ACL target > > cn=vaults,cn=kra,dc=bioinf,dc=local does not exist > > [26/May/2016:12:14:10 +0200] NSACLPlugin - The ACL target > > cn=ad,cn=etc,dc=bioinf,dc=local does not exist > > [26/May/2016:12:14:10 +0200] NSACLPlugin - The ACL target > cn=casigningcert > > cert-pki-ca,cn=ca_renewal,cn=ipa,cn=etc,dc=bioinf,dc=local does not > exist > > [26/May/2016:12:14:10 +0200] NSACLPlugin - The ACL target > cn=casigningcert > > cert-pki-ca,cn=ca_renewal,cn=ipa,cn=etc,dc=bioinf,dc=local does not > exist > > [26/May/2016:12:14:10 +0200] NSACLPlugin - The ACL target > cn=automember > > rebuild membership,cn=tasks,cn=config does not exist > > [26/May/2016:12:14:10 +0200] - Skipping CoS Definition cn=Password > > Policy,cn=accounts,dc=bioinf,dc=local--no CoS Templates found, which > should be > > added before the CoS Definition. > > [26/May/2016:12:14:10 +0200] schema-compat-plugin - > schema-compat-plugin > > tree scan will start in about 5 seconds! > > [26/May/2016:12:14:10 +0200] - slapd started. Listening on All > Interfaces > > port 389 for LDAP requests > > [26/May/2016:12:14:10 +0200] - Listening on All Interfaces port > 636 for > > LDAPS requests > > [26/May/2016:12:14:10 +0200] - Listening on > > /var/run/slapd-BIOINF-LOCAL.socket for LDAPI requests > > [26/May/2016:12:14:15 +0200] schema-compat-plugin - warning: no > entries set > > up under ou=sudoers,dc=bioinf,dc=local > > [26/May/2016:12:14:15 +0200] schema-compat-plugin - warning: no > entries set > > up under cn=ng, cn=compat,dc=bioinf,dc=local > > [26/May/2016:12:14:15 +0200] schema-compat-plugin - Finished > plugin > > initialization. > > > > > > On Mon, May 30, 2016 at 4:46 PM, Martin Kosek <mko...@redhat.com > <mailto:mko...@redhat.com> > > <mailto:mko...@redhat.com <mailto:mko...@redhat.com>>> wrote: > > > > On 05/30/2016 04:36 PM, Martin Basti wrote: > > > > > > > > > On 30.05.2016 14:20, seli irithyl wrote: > > >> Hi, > > >> > > >> Since last update, I'am unable to log in to web ui with FF (e.g. > blank page) > > >> Any idea where too look for ? > > >> > > >> Best regards, > > >> > > >> Seli > > >> > > >> > > >> > > >> > > >> > > > Hello, > > > > > > can you provide version of the freeIPA, firefox. Does it work > from > different > > > browser? does it work from private mode? > > > > + does [CTRL]+F5 helps? Do advise in > > http://www.freeipa.org/page/Troubleshooting#Web_UI > > help? > > > > > > > > -- Petr Vobornik -- 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] Enforce use of OTP token for all users.
On 05/16/2016 12:20 PM, Prashant Bapat wrote: > Any suggestions on how to achieve this ? > `ipa config-mod --user-auth-type=otp` will force otp auth for users with an OTP token. -- Petr Vobornik -- 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] Stuck at CA_UNREACHABLE and NEED_CSR_GEN_PIN
eku: id-kp-serverAuth,id-kp-clientAuth > pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad > post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert > "subsystemCert cert-pki-ca" > track: yes > auto-renew: yes > Request ID '20130519130744': > status: MONITORING > ca-error: Internal error: no response to > "http://host.example.net:9180/ca/ee/ca/profileSubmit?profileId=caServerCert_nu > m=64=true=true". > stuck: no > key pair storage: > type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS > Certificate > DB',pinfile='/etc/httpd/al > ias/pwdfile.txt' > certificate: > type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS > Certificate DB' > CA: dogtag-ipa-renew-agent > issuer: CN=Certificate Authority,O=example.NET > subject: CN=RA Subsystem,O=example.NET > expires: 2017-10-13 14:09:49 UTC > key usage: > digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment > eku: id-kp-serverAuth,id-kp-clientAuth > pre-save command: > post-save command: /usr/lib64/ipa/certmonger/renew_ra_cert > track: yes > auto-renew: yes > Request ID '20130519130745': > status: NEED_CSR_GEN_PIN > ca-error: Internal error: no response to > "http://host.example.net:9180/ca/ee/ca/profileSubmit?profileId=caServerCert_nu > m=63=true=true". > stuck: yes > key pair storage: > type=NSSDB,location='/var/lib/pki-ca/alias',nickname='Server-Cert > cert-pki-ca',token='NSS Certificate DB',p > in set > certificate: > type=NSSDB,location='/var/lib/pki-ca/alias',nickname='Server-Cert > cert-pki-ca',token='NSS Certificate DB' > CA: dogtag-ipa-renew-agent > issuer: CN=Certificate Authority,O=example.NET > subject: CN=host.example.net <http://host.example.net>,O=example.NET > expires: 2017-10-13 14:09:49 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 > > > Regards, Adam > > > -- Petr Vobornik -- 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] Looking for documentation for Python API
On 05/13/2016 11:49 AM, Alexander Bokovoy wrote: > On Thu, 12 May 2016, Jan Cholasta wrote: >> On 11.5.2016 10:52, Martin Kosek wrote: >>> On 05/07/2016 09:07 AM, Joshua J. Kugler wrote: >>>> On Friday, May 06, 2016 09:04:59 Martin Basti wrote: >>>>> since IPA4.2 web UI contains API browser (IPA Server/API Browser) >>>>> >>>>> So for example for caacl-add: >>>>> api.Command.caacl_add(u'argument-ca-acl-name', description=u"optional >>>>> description") >>>>> >>>>> you can try commands in "ipa console" it contains initialized API, >>>>> just >>>>> call api.Command.() >>>>> >>>>> API.txt provides the same information as API browser, but browser >>>>> looks >>>>> better :) >>>>> >>>>> Feel free to ask anything, if you identified gaps in docs which are >>>>> hard >>>>> to understand for non-IPA developer feel free report it, or feel >>>>> free to >>>>> create howTo in freeipa.org page. >>>> >>>> Thanks for the pointers. I'm looking at automating some user and group >>>> additions, group editing, etc. Am I right in assuming that anything >>>> that uses >>>> the api.Command. will require a kinit before it >>>> is run, >>>> even if it is via the Python API? If I want to use a user/pass from >>>> the script >>>> itself (and not have a shell script which does kinit, then fires off >>>> my Python >>>> script) would I be better off hitting the web API with sessions and >>>> JSON-RPC as >>>> detailed here: >>>> >>>> https://vda.li/en/posts/2015/05/28/talking-to-freeipa-api-with-sessions/ >>>> >>>> >>>> Put another way, since I want to hit the API from a system that >>>> might not have >>>> sssd installed, nor has joined the realm, I assume it would be >>>> *impossible* to >>>> use api.Command. as it relies on a Kerberos ticket? To >>>> put it yet >>>> another way: is there a way to hand a user/pass to the Python API and >>>> authenticate that way. >>> >>> The API itself can be hit with user/password, as noted in Alexander's >>> blog. If >>> you want to use the actual Python API, Kerberos may be the only way. >>> But I >>> think Jan or Petr may had some other (hacky) way to pass >>> user+password there too. >> >> I don't think we support anything but Kerberos on the client side in >> our Python API. It might be possible to somehow emulate what the web >> UI does, but I haven't personally ever attempted to do that. Petr, >> have you? > It should be relatively easy to update IPA cli code to accept a jar with > a cookie and use that if Kerberos ccache is missing or empty. > I implemented it a year ago, but the patch was not merged: https://www.redhat.com/archives/freeipa-devel/2015-May/msg00070.html -- Petr Vobornik -- 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] DHCP plugin (don't get your hopes up)
On 05/10/2016 09:39 PM, Jeffery Harrell wrote: > As promised yesterday, here’s the link to my bespoke DHCP plugin. It’s really > nothing, just a little thing I whipped up for my own use. > > https://github.com/jefferyharrell/IPA-dhcp > > Very nice. This is probably the most complex 'external' IPA plugin I've seen. You must have put quite a lot of effort into making it happen. Were there any areas in code/docs/wiki/... you encountered which you would like to see improved in FreeIPA or maybe some obstacles removed so that plugins like this can be made easier? Regards -- Petr Vobornik -- 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] Restore form backup , start servrer will error but sucess
On 05/10/2016 01:49 PM, Martin Basti wrote:
> No there is not python 2.7 on centos 6.x, maybe there is something wrong in
> the
> code, let me check first
How did you run the backup and restore? AFAIK it was introduced in
FreeIPA 3.2, then it was introduced in ipa 3.3 release on RHEL 7. It is
not on RHEL 6.
>
>
> On 10.05.2016 13:34, Barry wrote:
>>
>> Ipa 3.0 e47
>>
>> Centos 6.5 . Just update python?
>>
>> 2016年5月10日 下午6:58 於 "Martin Basti"
>> <<mailto:mba...@redhat.com>mba...@redhat.com> 寫道：
>>
>>
>>
>> On 10.05.2016 12:41, barry...@gmail.com <mailto:barry...@gmail.com>
>> wrote:
>>> Hi:
>>>
>>> Restore form backup follow the procedure below:
>>> http://www.freeipa.org/page/V3/Backup_and_Restore
>>>
>>> Now server web page launch but canot access
>>> Sorry you are not allowed to access this service.
>>>
>>> Starting dirsrv:
>>> PKI-IPA... [ OK ]
>>> WISERS-COM... [ OK ]
>>> Starting KDC Service
>>> Starting Kerberos 5 KDC: [ OK ]
>>> Starting KPASSWD Service
>>> Starting Kerberos 5 Admin Server: [ OK ]
>>> Starting MEMCACHE Service
>>> Starting ipa_memcached:[ OK ]
>>> Starting HTTP Service
>>> Starting httpd:[ OK ]
>>> Starting CA Service
>>>
>>>
>>> Starting CA Service
>>> Traceback (most recent call last):
>>> File "/usr/sbin/pki-server", line 88, in
>>> cli = PKIServerCLI()
>>> File "/usr/sbin/pki-server", line 34, in __init__
>>> super(PKIServerCLI, self).__init__('pki-server', 'PKI server
>>> command-line interface')
>>> File "/usr/lib/python2.6/site-packages/pki/cli.py", line 39, in
>>> __init__
>>> self.modules = collections.OrderedDict()
>>> AttributeError: 'module' object has no attribute 'OrderedDict'
>>> Starting pki-ca: [ OK ]
>>>
>>>
>>> Any idea above?
>>>
>>>
>>
>> You are using the old python, python 2.7 is required, which version of OS
>> and IPA do you use?
>> Martin
>>
>
>
>
--
Petr Vobornik
--
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] Upgrade to new IPA
On 05/10/2016 12:36 PM, barry...@gmail.com wrote: > Hi all: > > I m using freeipa 3.0 ...is there a fast way to export username / password > and > migrate to > new 4.0 server not inplace upgrade .? > The recommended method is to do an inplace upgrade to the latest RHEL/CentOS 6. Then migrate to RHEL 7 by creating a new replica, see the full process here: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/upgrading.html#migrating-ipa-proc -- Petr Vobornik -- 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-server-upgrade fails and CA cannot start
On 05/08/2016 09:49 PM, Andrew C. Dingman wrote: > For those of you who recognize me from non-public lists and chats, this > is a whole different setup from the one we've been discussing there. > > This is on a RHEL 7 system, and unfortunately for me the CA master in > my personal IPA realm. When I attempted to update using yum on April > 15th, the ipa-server-update script failed with what seems to be a dbus > error, and I have been unable to start the CA (and therefore ipa in > general) since. As a result, my personal systems are running on one IPA > server, which makes me more than a little nervous. > > The relevant bit of the upgrade log seems to be: > > 2016-05-08T19:03:08Z DEBUG stderr= > 2016-05-08T19:03:08Z INFO [Upgrading CA schema] > 2016-05-08T19:03:08Z DEBUG flushing ldapi://%2fvar%2frun%2fslapd- > ACDINGMAN-COM.socket from SchemaCache > 2016-05-08T19:03:08Z DEBUG retrieving schema for SchemaCache > url=ldapi://%2fvar%2frun%2fslapd-ACDINGMAN-COM.socket > conn= > 2016-05-08T19:03:08Z DEBUG Processing schema LDIF file > /usr/share/pki/server/conf/schema-certProfile.ldif > 2016-05-08T19:03:08Z DEBUG Not updating schema > 2016-05-08T19:03:08Z INFO CA schema update complete (no changes) > 2016-05-08T19:03:08Z INFO [Verifying that CA audit signing cert has 2 > year validity] > 2016-05-08T19:03:08Z DEBUG caSignedLogCert.cfg profile validity range > is 720 > 2016-05-08T19:03:08Z INFO [Update certmonger certificate renewal > configuration to version 4] > 2016-05-08T19:03:08Z DEBUG Loading StateFile from > '/var/lib/ipa/sysupgrade/sysupgrade.state' > 2016-05-08T19:03:08Z ERROR Failed to get request: bus, object_path and > dbus_interface must not be None. > 2016-05-08T19:03:08Z ERROR IPA server upgrade failed: Inspect > /var/log/ipaupgrade.log and run command ipa-server-upgrade manually. > 2016-05-08T19:03:08Z DEBUG File "/usr/lib/python2.7/site- > packages/ipapython/admintool.py", line 171, in execute > return_value = self.run() > File "/usr/lib/python2.7/site- > packages/ipaserver/install/ipa_server_upgrade.py", line 50, in run > raise admintool.ScriptError(str(e)) > > 2016-05-08T19:03:08Z DEBUG The ipa-server-upgrade command failed, > exception: ScriptError: bus, object_path and dbus_interface must not be > None. > 2016-05-08T19:03:08Z ERROR bus, object_path and dbus_interface must not > be None. > > There's a whole lot more, nearly 4MiB of log even when I reduce it to > my most recent attempt to run the upgrade script. > > "getcert list" successfully shows 8 certificate requests being tracked. > Four are in "MONITORING" status, four in "NEED_CA". The NEED_CA > requests all indicate expiration back in February, and look like > crucial certificates: CN=CA Subsystem, CN=IPA RA, CN=CA Audit > and CN=OCSP Subsystem. > > On the working replica, all eight are in "MONITORING" status and have > expiration dates in 2017 or later. I have not attempted the package > update on that system. Should I consider promoting this one to CA > master, force-deleting the old one, and reinstalling it as a new > system? > > Please let me know what other information would be helpful for > diagnostics. The current state of all packages on the broken master is > up to earlier today from the official Red Hat content distribution > network. > Hello Andrew, Could you paste output of `ipactl start` ? Also when upgrader fails it tends to leave directory server not accessible by changing 389 and 636 port. It could be verified by: $ ldapsearch -ZZ -h `hostname` -D "cn=Directory Manager" -W -s base -b "cn=config" | grep "nsslapd-security\|nsslapd-port" Enter LDAP Password: nsslapd-requiresrestart: cn=config:nsslapd-port nsslapd-port: 389 nsslapd-security: on If there are values other than '389' and 'on' (usually '0' and 'off') then it might the reason why IPA doesn't start. Changing them back to 'on' and 389 might help. But it won't say why the upgrader failed. Maybe it was a one-time glitch or it was related to the expired certs. The error message you got is in code which creates connection to certmonger. But if there are expired certificates. The usual recovery is to move back time a day or two before the first certificate expires and let certmonger to renew the certs. Optionally the renewal can be forced by `getcert resubmit -i $certid` command. -- Petr Vobornik -- 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] service cert to a host/member/service
On 05/05/2016 11:44 AM, lejeczek wrote: > On Wed, 2016-05-04 at 13:26 -0400, Rob Crittenden wrote: >> lejeczek wrote: >>> hi users, as one follows official docs and issues a certificate for a >>> service/host, one wonders what is the correct way to move such a >>> certificate >>> to a host(which is domain member) ? I understand certificates issued with: >>> $ >>> ipa cert-request -add --principal are stored in ldap backend, (yet I >>> don't >>> quite get the difference between that tool and ipa-certget). >> >> >> The first uses the IPA command-line to get a cert directly. ipa-getcert >> uses certmonger. >> >> If you are getting a certificate for another host, particularly if that >> host isn't an IPA client, then the first form is the way to go. >> >>> How do I get such a certificate off the server and to a host-not-server? >> >> >> $ ipa cert-show <serial#> --out cert.pem >> >>> In my case I'm hoping to use this certificate in apache+nss. I realize I >>> also >>> will need CA certificate on that host, which I got hold of with certutil >>> operated on /etc/dirsrv/slapd-MY-DOMAIN - if it's the right way? >> >> >> So in this case you'd want to generate the CSR on the host-not-server >> using certutil. You'd take that CSR to the enrolled host and run ipa >> cert-request ... >> >> Get a copy of the cert and get that and /etc/ipa/ca.crt to the > Is this the only place where IPA' CA cert resides? > I thought that that cert will be in /etc/dirsrv/slapd-MY-DOMAIN > $ certutil -d /etc/dirsrv/slapd-MY.. > gets me: > > MY-DOMAIN IPA CACT,C,C > Server-Certu,u,u > > what is that IPA CA then? > I also see the same with: > $ certutil -d /etc/httpd/alias -L > Is this the same one certificate? (including /etc/ipa/ca.crt) > > I get these with: ipa-getcert list > I'm guessing these are set up by installer and to be managed by certmonger, > for > DS and web server for certificates auto management purposes? You can use generic `getcert` tool to get all certs managed by certmonger and their location. It will show you also PKI internal certs. # getcert list `ipa-getcert list` is equivalent to `getcert list -c IPA` > > many thanks. > >> host-not-server. >> >> Use certutil to add both to your NSS database. >> >> rob >> > -- Petr Vobornik -- 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] Replication error
On 04/29/2016 09:54 AM, Anton Rubets wrote:
> Hi
> Yeap now request: error -1 (Can't contact LDAP server) errno 2 (No such file
> or directory) gone
> But still i have
> attrlist_replace - attr_replace (nsslapd-referral,
> ldap://ldap2.domain389/o%3Dipaca) failed.
> Maybe you can help to find out were i need to go? dirsrv, ldap, client, sssd
> etc
> Best Regards
> Anton Rubets
There is probably still some dangling RUV left in dirsrv o=ipaca suffix.
I'll repeat the procedure for future linking.
1. Get list of replicas with CA:
# ipa-csreplica-manage list
2. For *each* replica(here ipa1.example.test) get list of RUVs and its
replica ID:
# ldapsearch -ZZ -h ipa1.example.test -D "cn=Directory Manager" -W -b
"o=ipaca"
"(&(objectclass=nstombstone)(nsUniqueId=---))"
| grep "nsds50ruv\|nsDS5ReplicaId"
replica id looks like:
nsDS5ReplicaId: 6
ruv looks like:
nsds50ruv: {replica 6 ldap://ipa1.example.test:389} 56f3e7
note that it is wrapped and grepped, unwrapped RUV is e.g.:
nsds50ruv: {replica 6 ldap://ipa1.example.test:389} 56f3e2840006
57278b7e0006
You can see that RUV contains a replica ID (8 in the example).
"nsds50ruv: {replicageneration} 56f3e2830006" can be ignored.
3. Find all RUVs which doesn't have existing replica ID. Hint: If
replica wasn't reinstalled then hostname will also differ which is a
nice indicator of a dangling RUV.
4. Run clearuv task for each dangling RUV identified in step 3, here the
RUV is 13.
# ldapmodify -ZZ -D "cn=directory manager" -W -a
dn: cn=clean 13, cn=cleanallruv, cn=tasks, cn=config
objectclass: extensibleObject
replica-base-dn: o=ipaca
replica-id: 13
cn: clean 13
So if you have e.g. 3 replicas with CA with IDs 8, 12, 10 (note that
versions prior FreeIPA 4.3 have higher number for CA suffix) and
nsds50ruv shows only these IDs then you don't need to clean anything.
Full example:
# ipa-csreplica-manage list
Directory Manager password:
ipa1.example.test: master
ipa2.example.test: master
ipa3.example.test: master
# ldapsearch -ZZ -h ipa1.example.test ...
nsDS5ReplicaId: 6
nsds50ruv: {replicageneration} 56f3e2830006
nsds50ruv: {replica 6 ldap://ipa1.example.test:389} 56f3e2
nsds50ruv: {replica 5 ldap://ipa2.example.test:389} 56f3e2
nsds50ruv: {replica 8 ldap://ipa3.example.test:389} 56f3e7
# ldapsearch -ZZ -h ipa2.example.test ...
nsDS5ReplicaId: 5
nsds50ruv: {replicageneration} 56f3e2830006
nsds50ruv: {replica 5 ldap://ipa2.example.test:389} 56f3e2
nsds50ruv: {replica 8 ldap://ipa3.example.test:389} 56f3e7
nsds50ruv: {replica 3 ldap://ipa4.example.test:389} 56f3e1
nsds50ruv: {replica 6 ldap://ipa1.example.test:389} 56f3e2
# ldapsearch -ZZ -h ipa3.example.test ...
nsDS5ReplicaId: 8
nsds50ruv: {replicageneration} 56f3e2830006
nsds50ruv: {replica 8 ldap://ipa3.example.test:389} 56f3e7
nsds50ruv: {replica 5 ldap://ipa2.example.test:389} 56f3e2
nsds50ruv: {replica 9 ldap://ipa2.example.test:389} 56f3d2
nsds50ruv: {replica 6 ldap://ipa1.example.test:389} 56f3e2
Here the correct replica IDs are 8,5,5.
Dangling are 3,9. So the cleanall ruv task would be run for 3,9,
>
> From: Petr Vobornik <pvobo...@redhat.com>
> Sent: Thursday, April 28, 2016 1:49 PM
> To: Anton Rubets; freeipa-users@redhat.com
> Subject: Re: [Freeipa-users] Replication error
>
> On 04/26/2016 02:02 PM, Anton Rubets wrote:
>> Hhi all
>>
>> I have issues with replication between to FreeIPA server
>>
>> In maters log
>>
>> [26/Apr/2016:10:38:12 +0200] attrlist_replace - attr_replace
>> (nsslapd-referral,
>> ldap://ldap2.domain:389/o%3Dipaca) failed.
>> [26/Apr/2016:10:38:12 +0200] attrlist_replace - attr_replace
>> (nsslapd-referral,
>> ldap://ldap2.domain:389/o%3Dipaca) failed.
>> [26/Apr/2016:10:38:12 +0200] attrlist_replace - attr_replace
>> (nsslapd-referral,
>> ldap://ldap2.domain389/o%3Dipaca) failed.
>> [26/Apr/2016:10:39:35 +0200] slapi_ldap_bind - Error: could not send startTLS
>> request: error -1 (Can't contact LDAP server) errno 2 (No such file or
>> directory)
>>
>>
>> On replica server
>>
>>
>> [26/Apr/2016:08:38:12 +] attrlist_replace - attr_replace
>> (nsslapd-referral,
>> ldap://ldap1.domain:389/o%3Dipaca) failed.
>> [26/Apr/2016:08:43:13 +] attrlist_replace - attr_replace
>> (nsslapd-referral,
>> ldap://ldap1domain:389/o%3Dipaca) failed.
>> [26/Apr/2016:08:43:13 +] attrlist_replace - attr_replace
>> (nsslapd-referral,
>> ldap://ldap1.domain:389/o%3Dipaca) failed.
>> [26/Apr/2016:08:43:13 +] attrlist_replace - attr_replace
>> (nsslapd-referral,
>> ldap://ldap1.domain:389/o%3Dipaca) failed.
>
&g
Re: [Freeipa-users] ipa-client password authentication failed
On 05/02/2016 02:05 AM, siology.io wrote: > That plugins.py file does exist, but it's totally empty. Following should be the content of the file. Adding it there should fix the issue. https://git.fedorahosted.org/cgit/freeipa.git/tree/install/wsgi/plugins.py Question how it got into the state. What IPA version from what repository do you use? Have you done any manual changes there? > > And yes, all i get on the browser is an empty white screen window, That is most-likely a result of the above. > > On 30 April 2016 at 02:20, Petr Vobornik <pvobo...@redhat.com > <mailto:pvobo...@redhat.com>> wrote: > > On 04/29/2016 12:44 AM, siology.io <http://siology.io> wrote: > > On a clean centos 7 VM, after installation of ipa-server browsing to > the ipa web > > UI gets me in the httpd error_logs: > > > > [Thu Apr 28 18:41:11.826134 2016] [:error] [pid 10162] > [remote10.0.4.10:244 <http://10.0.4.10:244> > > <http://10.0.4.10:244>] mod_wsgi (pid=10162): Target WSGI script > > '/usr/share/ipa/wsgi/plugins.py' does not contain WSGI application > 'application'. > > > > Is this a known issue ? I didn't get much out of google. > > > > I don't see this issue on RHEL 7.2 nor FreeIPA 4.3.x on F23. Could you > paste here content of your /usr/share/ipa/wsgi/plugins.py file? > > Does it prevent to load Web UI? > -- > Petr Vobornik > > -- Petr Vobornik -- 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] is it possible to use 'ipa-replica' to sync userbetween different suffix AD and IPA domain?
On 04/28/2016 05:30 PM, Matrix wrote: > Hi, Petr > > Thanks for your quickly reply. > > I want to integrated linux servers with existed AD, centralized manage > HBAC/Sudo > rules. > > So i have setup a standalone IPA server with domain 'example.net', trying to > sync users from existed AD to it with following cmd: > > ipa-replica-manage connect --winsync > --binddn="cn=ipa,cn=users,dc=examplemedia,dc=net" --bindpw='' > --passsync='' --cacert='/etc/openldap/cacerts/ipaad.cer' > --win-subtree='ou=users,dc=examplemedia,dc=net' -v ipaad.examplemedia.net > > > After it has been successfully established, users in AD did not sync to IPA. Before we go into debugging, please make sure that you have done the steps described in section 7.4 of Windows integration guide: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Windows_Integration_Guide/Setting_up_Active_Directory.html > > > For 'trusts' integration method, since user did not sync to IPA at all, how > to > set sudo/HBAC rules for users? I have not tried it. > > > Matrix > > > > > -- Original -- > *From: * "Petr Vobornik";<pvobo...@redhat.com>; > *Date: * Thu, Apr 28, 2016 11:21 PM > *To: * "Matrix"<matrix...@qq.com>; "freeipa-users"<freeipa-users@redhat.com>; > *Subject: * Re: [Freeipa-users] is it possible to use 'ipa-replica' to sync > userbetween different suffix AD and IPA domain? > > On 04/28/2016 04:44 PM, Matrix wrote: > > Hi, all > > > > I am trying to do a centrelized solution > > > > AD domain is 'examplemedia.net' > > > > IPA domain is 'example.net' > > > > After ipa-replica has been established, i found that nothing has been > synced > > from AD to IPA. > > > > IPA version: ipa-server-4.2.0-15.0.1.el7.centos.6.1.x86_64 > > > > I doubt that for different suffix is supported ? If so, anyone can show > some > > hint for me to investigate more? > > > > Thanks for your kindly help. > > > > Matrix > > Hello, > > what is your goal and current setup? > > By "ipa-replica has been established" do you mean that you installed a > new currently standalone IPA server? And connected it somehow with AD? > > Or did you run `ipa-replica-manage connect --winsync ...` > > It would be good to mention that IPA server[1] cannot be a replica of an > AD server. But it can integrate with it. Either by using > winsync(synchronization) or the recommended solution: Trusts [2]. > > Documentation: > [1] > https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/index.html > [2] > https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Windows_Integration_Guide/pt02.html > > HTH > -- > Petr Vobornik > -- Petr Vobornik -- 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-client password authentication failed
On 04/29/2016 12:44 AM, siology.io wrote: > On a clean centos 7 VM, after installation of ipa-server browsing to the ipa > web > UI gets me in the httpd error_logs: > > [Thu Apr 28 18:41:11.826134 2016] [:error] [pid 10162] [remote 10.0.4.10:244 > <http://10.0.4.10:244>] mod_wsgi (pid=10162): Target WSGI script > '/usr/share/ipa/wsgi/plugins.py' does not contain WSGI application > 'application'. > > Is this a known issue ? I didn't get much out of google. > I don't see this issue on RHEL 7.2 nor FreeIPA 4.3.x on F23. Could you paste here content of your /usr/share/ipa/wsgi/plugins.py file? Does it prevent to load Web UI? -- Petr Vobornik -- 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 server having cert issues
On 04/29/2016 02:53 PM, Bret Wortman wrote: > Despite "ipactl status" indicating that all processes were running after > step 1, step 2 produces "Unable to establish SSL connection." > > Full terminal session is at http://pastebin.com/ZuNBHPy0 Hm, it doesn't help me much. Does it contact the correct machine? I.e., is IP address OK? What is the result of: netstat -ln | grep 443 netstat -ln | grep 8009 Have you modified by any chance: /etc/httpd/conf.d/ipa-pki-proxy.conf Try to run curl, maybe it will be more verbose, but probably not: # curl -v https://zsipa.private.net:443/ca/admin/ca/getStatus Christian(CCd), do you have any ideas? Could you look into /var/log/httpd/error_log or syslog(would try /var/log/message and journalctl), There might be more information about the: """ status: NEED_TO_SUBMIT ca-error: Internal error """ Which may help us with root culprit. Do web ui or CLI work? > > On 04/29/2016 07:29 AM, Petr Vobornik wrote: >> On 04/29/2016 12:03 PM, Bret Wortman wrote: >>> The date change was due (I think) to me changing the date back to 4/1 >>> yesterday, though I left it there and haven't updated it again until >>> this morning, when I went back to 4/1 again. >>> >>> I put the results of the commands you requested at >>> https://pastebin.com/s7cHAh6R. Thanks for your help, Petr. I really >>> appreciate it. >>> >>> >>> Bret >> If I combine this and the previous output, it seems that: >> >> - PKI starts normally >> - ipactl has troubles with determining that PKI started and after 5mins >> of failed attempts it stops whole IPA (expected behavior when a service >> doesn't start) >> >> The failed attempt is: >> """ >> ipa: DEBUG: Waiting until the CA is running >> ipa: DEBUG: Starting external process >> ipa: DEBUG: args='/usr/bin/wget' '-S' '-O' '-' '--timeout=30' >> '--no-check-certificate' >> 'https://zsipa.private.net:443/ca/admin/ca/getStatus' >> ipa: DEBUG: Process finished, return code=4 >> ipa: DEBUG: stdout= >> ipa: DEBUG: stderr=--2016-04-01 09:39:50-- >> https://zsipa.private.net/ca/admin/ca/getStatus >> Resolving zsipa.private.net (zsipa.private.net)... 192.168.208.53 >> Connecting to zsipa.private.net >> (zsipa.private.net)|192.168.208.53|:443... connected. >> Unable to establish SSL connection. >> >> ipa: DEBUG: The CA status is: check interrupted due to error: Command >> ''/usr/bin/wget' '-S' '-O' '-' '--timeout=30' '--no-check-certificate' >> 'https://zsipa.private.net:443/ca/admin/ca/getStatus'' returned non-zero >> exit status 4 >> """ >> >> It says "Unable to establish SSL connection", it would be good to get >> more details. >> >> Also given that the CA cert was renewed on April 3rd and that all certs >> expires after that date, we should rather use date April 4th when moving >> the date back. >> >> So first start IPA again (date April 4th) but force it to not stop >> services >> >> 1. ipactl start --force >> wait until all is started >> 2. wget -v -d -S -O - --timeout=30 --no-check-certificate >> https://zsipa.private.net:443/ca/admin/ca/getStatus >> >> optionally (assuming that CA won't be turned of) >> 3. getcert list >> > -- Petr Vobornik -- 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 server having cert issues
On 04/29/2016 02:53 PM, Bret Wortman wrote: > Despite "ipactl status" indicating that all processes were running after > step 1, step 2 produces "Unable to establish SSL connection." > > Full terminal session is at http://pastebin.com/ZuNBHPy0 > > On 04/29/2016 07:29 AM, Petr Vobornik wrote: >> On 04/29/2016 12:03 PM, Bret Wortman wrote: >>> The date change was due (I think) to me changing the date back to 4/1 >>> yesterday, though I left it there and haven't updated it again until >>> this morning, when I went back to 4/1 again. >>> >>> I put the results of the commands you requested at >>> https://pastebin.com/s7cHAh6R. Thanks for your help, Petr. I really >>> appreciate it. I cannot view the pastebin: """ This is a private paste. If you created this paste, please login to view it. """ >>> >>> >>> Bret >> If I combine this and the previous output, it seems that: >> >> - PKI starts normally >> - ipactl has troubles with determining that PKI started and after 5mins >> of failed attempts it stops whole IPA (expected behavior when a service >> doesn't start) >> >> The failed attempt is: >> """ >> ipa: DEBUG: Waiting until the CA is running >> ipa: DEBUG: Starting external process >> ipa: DEBUG: args='/usr/bin/wget' '-S' '-O' '-' '--timeout=30' >> '--no-check-certificate' >> 'https://zsipa.private.net:443/ca/admin/ca/getStatus' >> ipa: DEBUG: Process finished, return code=4 >> ipa: DEBUG: stdout= >> ipa: DEBUG: stderr=--2016-04-01 09:39:50-- >> https://zsipa.private.net/ca/admin/ca/getStatus >> Resolving zsipa.private.net (zsipa.private.net)... 192.168.208.53 >> Connecting to zsipa.private.net >> (zsipa.private.net)|192.168.208.53|:443... connected. >> Unable to establish SSL connection. >> >> ipa: DEBUG: The CA status is: check interrupted due to error: Command >> ''/usr/bin/wget' '-S' '-O' '-' '--timeout=30' '--no-check-certificate' >> 'https://zsipa.private.net:443/ca/admin/ca/getStatus'' returned non-zero >> exit status 4 >> """ >> >> It says "Unable to establish SSL connection", it would be good to get >> more details. >> >> Also given that the CA cert was renewed on April 3rd and that all certs >> expires after that date, we should rather use date April 4th when moving >> the date back. >> >> So first start IPA again (date April 4th) but force it to not stop >> services >> >> 1. ipactl start --force >> wait until all is started >> 2. wget -v -d -S -O - --timeout=30 --no-check-certificate >> https://zsipa.private.net:443/ca/admin/ca/getStatus >> >> optionally (assuming that CA won't be turned of) >> 3. getcert list >> > -- Petr Vobornik -- 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] OTP and time step size
On 04/29/2016 12:37 PM, Prashant Bapat wrote: > Hi Petr, > > Thanks for the response. But my question was more towards the cases where > there > is a slight delay in entering the OTP in the web UI and it reaching the IPA > server. This actually can happen with ANY time window. > > There are couple of scenarios. > > 1. Network delays. > 2. User enters the OTP token and takes a few seconds before pressing submit. > 3. User has to enter OTP first and then the password. This is the case when > changing password in IPA at the moment when OTP is on. Actually password change scenario is: 1. oldpassword + otp 2. old password + otp2 + new password + confirm new password > > Is there a way to make IPA honor either the current token (obviously!) or 1 > elapsed token? Actually it may be done this way, but I'm not sure. > > This will go a long way in making FreeIPA's OTP implementation much more > usable. Either way, as I said in the previous mail, try HOTP tokens. They don't use time windows and therefore the above is not an issue. > > Thanks. > --Prashant > > On 25 April 2016 at 21:48, Petr Vobornik <pvobo...@redhat.com > <mailto:pvobo...@redhat.com>> wrote: > > On 04/22/2016 08:55 AM, Prashant Bapat wrote: > > Hi, > > > > We have been using the OTP feature of FreeIPA extensively for users to > login to > > the web UI. Now we are rolling out an external service using the LDAP > > authentication based on FreeIPA and OTP. > > > > End users typically login rarely to the web UI. Only to update their > SSH keys > > once in 90 days. > > > > However to the new service based on FreeIPA's LDAP they would be > logging in > > multiple times daily. > > > > Here is an observation: FreeIPA's OTP mechanism is very stringent in > requiring > > the current token to be inside the 30 second window. Because of this > there might > > be a sizable percentage of users who will have to retry login. > Obviously, this > > is a bad user experience. > > > > As per the RFC-6238 <http://www.rfc-base.org/txt/rfc-6238.txt> section > 5.2, we > > could allow 1 time step and make the user experience better. > > > > Can this be done by changing a config or does it involve a > patch/code-change. > > Any pointers to this appreciated. > > > > Thanks. > > --Prashant > > > > FreeIPA works with both time based OTP tokens(TOTP) and counter based > OTP tokens(HOTP). TOTP uses 30s time interval by default. Administrator > can set custom clock interval during creation of a token. But > self-service Web UI doesn't show this option. Users can still use it in > CLI though. > > Alternative is HOTP which doesn't use time interval and there the UX > issue is not there. It can be also created in user self service. > -- > Petr Vobornik > > -- Petr Vobornik -- 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 server having cert issues
On 04/29/2016 12:03 PM, Bret Wortman wrote: > The date change was due (I think) to me changing the date back to 4/1 > yesterday, though I left it there and haven't updated it again until > this morning, when I went back to 4/1 again. > > I put the results of the commands you requested at > https://pastebin.com/s7cHAh6R. Thanks for your help, Petr. I really > appreciate it. > > > Bret If I combine this and the previous output, it seems that: - PKI starts normally - ipactl has troubles with determining that PKI started and after 5mins of failed attempts it stops whole IPA (expected behavior when a service doesn't start) The failed attempt is: """ ipa: DEBUG: Waiting until the CA is running ipa: DEBUG: Starting external process ipa: DEBUG: args='/usr/bin/wget' '-S' '-O' '-' '--timeout=30' '--no-check-certificate' 'https://zsipa.private.net:443/ca/admin/ca/getStatus' ipa: DEBUG: Process finished, return code=4 ipa: DEBUG: stdout= ipa: DEBUG: stderr=--2016-04-01 09:39:50-- https://zsipa.private.net/ca/admin/ca/getStatus Resolving zsipa.private.net (zsipa.private.net)... 192.168.208.53 Connecting to zsipa.private.net (zsipa.private.net)|192.168.208.53|:443... connected. Unable to establish SSL connection. ipa: DEBUG: The CA status is: check interrupted due to error: Command ''/usr/bin/wget' '-S' '-O' '-' '--timeout=30' '--no-check-certificate' 'https://zsipa.private.net:443/ca/admin/ca/getStatus'' returned non-zero exit status 4 """ It says "Unable to establish SSL connection", it would be good to get more details. Also given that the CA cert was renewed on April 3rd and that all certs expires after that date, we should rather use date April 4th when moving the date back. So first start IPA again (date April 4th) but force it to not stop services 1. ipactl start --force wait until all is started 2. wget -v -d -S -O - --timeout=30 --no-check-certificate https://zsipa.private.net:443/ca/admin/ca/getStatus optionally (assuming that CA won't be turned of) 3. getcert list -- Petr Vobornik -- 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 server having cert issues
in/tomcat-juli.jar:/usr/lib/java/commons-daemon.j > Apr 01 11:07:53 zsipa.private.net server[7974]: main class used: > org.apache.catalina.startup.Bootstrap > Apr 01 11:07:53 zsipa.private.net server[7974]: flags used: > -DRESTEASY_LIB=/usr/share/java/resteasy > Apr 01 11:07:53 zsipa.private.net server[7974]: options used: > -Dcatalina.base=/var/lib/pki/pki-tomcat -Dcatalina.home=/usr/share/tomcat > -Djava.endorsed.dirs= -Djava.io. > Apr 01 11:07:53 zsipa.private.net server[7974]: arguments used: stop > Apr 01 11:07:53 zsipa.private.net server[7974]: Apr 01, 2016 11:07:53 AM > org.apache.catalina.startup.ClassLoaderFactory validateFile > Apr 01 11:07:53 zsipa.private.net server[7974]: WARNING: Problem with JAR > file > [/var/lib/pki/pki-tomcat/lib/log4j.jar], exists: [false], canRead: [false] > Apr 01 11:07:54 zsipa.private.net server[6896]: Apr 01, 2016 11:07:54 AM > org.apache.catalina.core.StandardServer await > Apr 01 11:07:54 zsipa.private.net server[6896]: INFO: A valid shutdown > command > was received via the shutdown port. Stopping the Server instance. > Apr 01 11:07:54 zsipa.private.net server[6896]: Apr 01, 2016 11:07:54 AM > org.apache.coyote.AbstractProtocol pause > Apr 01 11:07:54 zsipa.private.net server[6896]: INFO: Pausing ProtocolHandler > ["http-bio-8080"] > > # systemctl status pki-tomcatd@pki-tomcat.service -l > ● pki-tomcatd@pki-tomcat.service - PKI Tomcat Server pki-tomcat > Loaded: loaded (/usr/lib/systemd/system/pki-tomcatd@.service; enabled) > Active: inactive (dead) > > Apr 28 12:12:53 zsipa.private.net server[8557]: Apr 28, 2016 12:12:53 PM > org.apache.catalina.core.StandardServer await > Apr 28 12:12:53 zsipa.private.net server[8557]: INFO: A valid shutdown > command > was received via the shutdown port. Stopping the Server instance. > Apr 28 12:12:53 zsipa.private.net server[8557]: Apr 28, 2016 12:12:53 PM > org.apache.coyote.AbstractProtocol pause > Apr 28 12:12:53 zsipa.private.net server[8557]: INFO: Pausing ProtocolHandler > ["http-bio-8080"] > Apr 28 12:12:53 zsipa.private.net server[8557]: Apr 28, 2016 12:12:53 PM > org.apache.coyote.AbstractProtocol pause > Apr 28 12:12:53 zsipa.private.net server[8557]: INFO: Pausing ProtocolHandler > ["http-bio-8443"] > Apr 28 12:12:53 zsipa.private.net server[8557]: Apr 28, 2016 12:12:53 PM > org.apache.coyote.AbstractProtocol pause > Apr 28 12:12:53 zsipa.private.net server[8557]: INFO: Pausing ProtocolHandler > ["ajp-bio-127.0.0.1-8009"] > Apr 28 12:12:53 zsipa.private.net server[8557]: Apr 28, 2016 12:12:53 PM > org.apache.catalina.core.StandardService stopInternal > Apr 28 12:12:53 zsipa.private.net server[8557]: INFO: Stopping service > Catalina Why is the time different here? Given that the PKI server seems to start could you: 1. move date to Apr 1 2. # date 3. # ipactl stop 4. # date 5. # ipactl start -d 6. # date 7. # ipactl status 8. # getcert list 9. # journalctl -u pki-tomcatd@pki-tomcat.service paste here output of 1-8. Plus output of 9 since date in 2. Or ideally attach it as text file so that lines won't be wrapped(hard to read). > > > > # systemctl | grep dirsrv@ > dirsrv@PRIVATE-NET.service > loaded active running 389 Directory Server > PRIVATE-NET. > > On 04/28/2016 12:04 PM, Petr Vobornik wrote: >> On 04/28/2016 05:49 PM, Bret Wortman wrote: >>> My system shows pki-server is installed and V10.2.1-3.fc21, but I don't >>> have the pki-server binary itself. Will reinstalling this rpm hurt me in >>> any way? Without it, I'm not sure how to check my system against the >>> messages you provided below. >> Not sure what you mean. Running doesn't require any additional packages. >> It is just to get additional logs. >>systemctl statuspki-tomcatd@pki-tomcat.service >>journalctl -upki-tomcatd@pki-tomcat.service >> >> And the links below are about checking if CA users have correctly mapped >> certificates in LDAP database in ou=people,o=ipaca for that you need >> only ldapsearch command and start directory server: We may skip this part, it might not be needed. >>systemctl startdirsrv@YOUR-REALM-TEST.service >> >> Proper name fordirsrv@YOUR-REALM-TEST.service can be found using: >>systemctl | grep dirsrv@ >> >> >>> On 04/28/2016 11:07 AM, Petr Vobornik wrote: >>>> On 04/28/2016 04:07 PM, Bret Wortman wrote: >>>>> Okay. This morning, I turned back time to 4/1 and started up IPA. It >>>>> didn't >>>>> work, but I got something new and interesting in the debug log, which >>>>> I've >>>>> posted tohttp://pastebin.com/M9VGCS8A. Lots of garbled
Re: [Freeipa-users] IPA server having cert issues
On 04/28/2016 05:49 PM, Bret Wortman wrote: > My system shows pki-server is installed and V10.2.1-3.fc21, but I don't > have the pki-server binary itself. Will reinstalling this rpm hurt me in > any way? Without it, I'm not sure how to check my system against the > messages you provided below. Not sure what you mean. Running doesn't require any additional packages. It is just to get additional logs. systemctl status pki-tomcatd@pki-tomcat.service journalctl -u pki-tomcatd@pki-tomcat.service And the links below are about checking if CA users have correctly mapped certificates in LDAP database in ou=people,o=ipaca for that you need only ldapsearch command and start directory server: systemctl start dirsrv@YOUR-REALM-TEST.service Proper name for dirsrv@YOUR-REALM-TEST.service can be found using: systemctl | grep dirsrv@ > > On 04/28/2016 11:07 AM, Petr Vobornik wrote: >> On 04/28/2016 04:07 PM, Bret Wortman wrote: >>> Okay. This morning, I turned back time to 4/1 and started up IPA. It >>> didn't >>> work, but I got something new and interesting in the debug log, which >>> I've >>> posted to http://pastebin.com/M9VGCS8A. Lots of garbled junk came >>> pouring out >>> which doesn't happen when I'm set to real time. Is /this/ significant? >> Anything in >>systemctl status pki-tomcatd@pki-tomcat.service >> or rather: >>journalctl -u pki-tomcatd@pki-tomcat.service >> ? >> >> Just to be sure, it might be also worth to check if CA subsystem users >> have correct certs assigned: >> * >> https://www.redhat.com/archives/freeipa-users/2016-April/msg00138.html >> * >> https://www.redhat.com/archives/freeipa-users/2016-April/msg00143.html >> >>> >>> On 04/27/2016 02:24 PM, Bret Wortman wrote: >>>> I put excerpts from the ca logs in http://pastebin.com/gYgskU79. It >>>> looks >>>> logical to me, but I can't spot anything that looks like a root >>>> cause error. >>>> The selftests are all okay, I think. The debug log might have >>>> something, but >>>> it might also just be complaining about ldap not being up because >>>> it's not. >>>> >>>> >>>> On 04/27/2016 01:11 PM, Rob Crittenden wrote: >>>>> Bret Wortman wrote: >>>>>> So in lieu of fixing these certs, is there an acceptable way to dump >>>>>> them all and start over /without losing the contents of the IPA >>>>>> database/? Or otherwise really screwing ourselves? >>>>> I don't believe there is a way. >>>>> >>>>>> We have a replica that's still up and running and we've switched >>>>>> everyone over to talking to it, but we're at risk with just the one. >>>>> I'd ignore the two unknown certs for now. They look like someone was >>>>> experimenting with issuing a cert and didn't quite get things working. >>>>> >>>>> The CA seems to be throwing an error. I'd check the syslog for >>>>> messages from >>>>> certmonger and look at the CA debug log and selftest log. >>>>> >>>>> rob >>>>> >>>> [snip] >>>> >>> >>> >> > -- Petr Vobornik -- 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] is it possible to use 'ipa-replica' to sync user between different suffix AD and IPA domain?
On 04/28/2016 04:44 PM, Matrix wrote: > Hi, all > > I am trying to do a centrelized solution > > AD domain is 'examplemedia.net' > > IPA domain is 'example.net' > > After ipa-replica has been established, i found that nothing has been synced > from AD to IPA. > > IPA version: ipa-server-4.2.0-15.0.1.el7.centos.6.1.x86_64 > > I doubt that for different suffix is supported ? If so, anyone can show some > hint for me to investigate more? > > Thanks for your kindly help. > > Matrix Hello, what is your goal and current setup? By "ipa-replica has been established" do you mean that you installed a new currently standalone IPA server? And connected it somehow with AD? Or did you run `ipa-replica-manage connect --winsync ...` It would be good to mention that IPA server[1] cannot be a replica of an AD server. But it can integrate with it. Either by using winsync(synchronization) or the recommended solution: Trusts [2]. Documentation: [1] https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/index.html [2] https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Windows_Integration_Guide/pt02.html HTH -- Petr Vobornik -- 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 server having cert issues
On 04/28/2016 04:07 PM, Bret Wortman wrote: > Okay. This morning, I turned back time to 4/1 and started up IPA. It didn't > work, but I got something new and interesting in the debug log, which I've > posted to http://pastebin.com/M9VGCS8A. Lots of garbled junk came pouring out > which doesn't happen when I'm set to real time. Is /this/ significant? Anything in systemctl status pki-tomcatd@pki-tomcat.service or rather: journalctl -u pki-tomcatd@pki-tomcat.service ? Just to be sure, it might be also worth to check if CA subsystem users have correct certs assigned: * https://www.redhat.com/archives/freeipa-users/2016-April/msg00138.html * https://www.redhat.com/archives/freeipa-users/2016-April/msg00143.html > > > On 04/27/2016 02:24 PM, Bret Wortman wrote: >> I put excerpts from the ca logs in http://pastebin.com/gYgskU79. It looks >> logical to me, but I can't spot anything that looks like a root cause error. >> The selftests are all okay, I think. The debug log might have something, but >> it might also just be complaining about ldap not being up because it's not. >> >> >> On 04/27/2016 01:11 PM, Rob Crittenden wrote: >>> Bret Wortman wrote: >>>> So in lieu of fixing these certs, is there an acceptable way to dump >>>> them all and start over /without losing the contents of the IPA >>>> database/? Or otherwise really screwing ourselves? >>> >>> I don't believe there is a way. >>> >>>> We have a replica that's still up and running and we've switched >>>> everyone over to talking to it, but we're at risk with just the one. >>> >>> I'd ignore the two unknown certs for now. They look like someone was >>> experimenting with issuing a cert and didn't quite get things working. >>> >>> The CA seems to be throwing an error. I'd check the syslog for messages >>> from >>> certmonger and look at the CA debug log and selftest log. >>> >>> rob >>> >> [snip] >> > > > -- Petr Vobornik -- 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] Replication error
On 04/26/2016 02:02 PM, Anton Rubets wrote: > Hhi all > > I have issues with replication between to FreeIPA server > > In maters log > > [26/Apr/2016:10:38:12 +0200] attrlist_replace - attr_replace > (nsslapd-referral, > ldap://ldap2.domain:389/o%3Dipaca) failed. > [26/Apr/2016:10:38:12 +0200] attrlist_replace - attr_replace > (nsslapd-referral, > ldap://ldap2.domain:389/o%3Dipaca) failed. > [26/Apr/2016:10:38:12 +0200] attrlist_replace - attr_replace > (nsslapd-referral, > ldap://ldap2.domain389/o%3Dipaca) failed. > [26/Apr/2016:10:39:35 +0200] slapi_ldap_bind - Error: could not send startTLS > request: error -1 (Can't contact LDAP server) errno 2 (No such file or > directory) > > > On replica server > > > [26/Apr/2016:08:38:12 +] attrlist_replace - attr_replace > (nsslapd-referral, > ldap://ldap1.domain:389/o%3Dipaca) failed. > [26/Apr/2016:08:43:13 +] attrlist_replace - attr_replace > (nsslapd-referral, > ldap://ldap1domain:389/o%3Dipaca) failed. > [26/Apr/2016:08:43:13 +] attrlist_replace - attr_replace > (nsslapd-referral, > ldap://ldap1.domain:389/o%3Dipaca) failed. > [26/Apr/2016:08:43:13 +] attrlist_replace - attr_replace > (nsslapd-referral, > ldap://ldap1.domain:389/o%3Dipaca) failed. This is a symptom of dangling RUVs (replica update vector) of previously removed replicas. It happens when replica is removed using: # ipa-replica-manage del $replica # ipa-server-install --uninstall (on replica) without running: # ipa-csreplica-manage del $replica first resolution is to clear the RUVs manually using clean ruv DS task becase ipa-csreplica-manage doesn't have support for it. FreeIPA 4.4 will receive a new command which will handle bot suffixes automatically - #5411. The instructions can found on the list: * https://www.redhat.com/archives/freeipa-users/2015-June/msg00386.html * https://www.redhat.com/archives/freeipa-users/2015-June/msg00416.html and * http://www.port389.org/docs/389ds/FAQ/troubleshoot-cleanallruv.html * or general procedure for future feature: https://fedorahosted.org/freeipa/ticket/5411#comment:7 Important: Be very careful not to remove RUVs of existing replicas. > > > And i can't find source of this problem. I have checked permission and etc. > As > i see replica is working but this message disturb my email every few minutes > and > i wanna somehow fix this. Also I just migrate from 3.0 to 4.2. > Info: > Master : > rpm -qa | grep ipa > ipa-server-dns-4.2.0-15.0.1.el7.centos.6.x86_64 > ipa-admintools-4.2.0-15.0.1.el7.centos.6.x86_64 > sssd-ipa-1.13.0-40.el7_2.2.x86_64 > ipa-client-4.2.0-15.0.1.el7.centos.6.x86_64 > libipa_hbac-1.13.0-40.el7_2.2.x86_64 > python-libipa_hbac-1.13.0-40.el7_2.2.x86_64 > python-iniparse-0.4-9.el7.noarch > ipa-python-4.2.0-15.0.1.el7.centos.6.x86_64 > ipa-server-4.2.0-15.0.1.el7.centos.6.x86_64 > > Replica: > rpm -qa | grep ipa > sssd-ipa-1.13.0-40.el7_2.2.x86_64 > ipa-admintools-4.2.0-15.0.1.el7.centos.6.1.x86_64 > libipa_hbac-1.13.0-40.el7_2.2.x86_64 > ipa-client-4.2.0-15.0.1.el7.centos.6.1.x86_64 > ipa-python-4.2.0-15.0.1.el7.centos.6.1.x86_64 > ipa-server-dns-4.2.0-15.0.1.el7.centos.6.1.x86_64 > python-libipa_hbac-1.13.0-40.el7_2.2.x86_64 > python-iniparse-0.4-9.el7.noarch > ipa-server-4.2.0-15.0.1.el7.centos.6.1.x86_64 > > > Best Regards > Anton Rubets -- Petr Vobornik -- 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 server having cert issues
On 04/26/2016 06:00 PM, Bret Wortman wrote: > # getcert list | grep expires > expires: 2018-04-02 13:04:51 UTC > expires: 2018-04-02 13:04:31 UTC > expires: unknown > expires: 2016-04-17 18:19:19 UTC > expires: 2016-04-17 18:19:18 UTC > expires: 2016-04-17 18:19:19 UTC > expires: 2016-04-01 20:16:39 UTC > expires: 2016-04-17 18:19:35 UTC > expires: 2016-03-11 13:04:29 UTC > expires: unknown > # > > So some got updated and most didn't. Is there a recommended way to update > these > all? The system is still backdated to 3 April (ntpd disabled) at this point. It's usually good to start renewing(when it doesn't happen automatically from some reason) with the cert which is about to expired first, i.e. the one with "2016-03-11 13:04:29" The process is: - move date before the cert is about to expired - leave it up to certmonger or manually force resubmit by `getcert resubmit -i $REQUEST_ID`, where request ID is in `getcert list` output. I'm little worried about the fact that CA cert was renewed at date which is after expiration of the other certs. Also the `expires: unknown` doesn't look good. Check `getcert list` output for errors related to the cert. > > > Bret > > > On 04/26/2016 11:46 AM, Petr Vobornik wrote: >> On 04/26/2016 03:26 PM, Bret Wortman wrote: >>> On our non-CA IPA server, this is happening, in case it's related and >>> illustrative: >>> >>> # ipa host-del zw113.private.net >>> ipa: ERROR: Certificate format error: (SEC_ERROR_LEGACY_DATABASE) The >>> certificate/key database is in an old, unsupported format. >>> # >> I would start with checking on all IPA servers if and what certificates >> are expired: >># getcert list >> or short version to check if there are any: >># getcert list | grep expires >> >> When CA cert is renewed, it is not automatically transfered to clients. >> There one must run: >># ipa-certupdate >> >>> On 04/26/2016 09:24 AM, Bret Wortman wrote: >>>> I rolled the date on the IPA server in question back to April 1 and ran >>>> "ipa-cacert-manage renew", which said it completed successfully. I rolled >>>> the >>>> date back to current and tried restarting ipa using ipactl stop && ipactl >>>> start, but no joy. No more ca renewal errors, but right after the pause I >>>> see >>>> this in /var/log/messages: >>>> >>>> systemd: kadmin.service: main process exited, code=exited, >>>> status=2/INVALIDARGUMENT >>>> systemd: Unit kadmin.service entered failed state. >>>> systemd: kadmin.service failed. >>>> >>>> I rebooted the server just in case, and it's still getting stuck at the >>>> same >>>> place. ipa-otpd doesn't get around to starting. >>>> >>>> >>>> Bret >>>> >>>> After the several-minutes-long pause after ipactl start outputs "Starting >>>> pki-tomcatd Service", I get the >>>> >>>> On 04/26/2016 08:14 AM, Bret Wortman wrote: >>>>> I have an IPA server on a private network which has apparently run into >>>>> certificate issues this morning. It's been running without issue for >>>>> quite a >>>>> while, and is on 4.1.4-1 on fedora 21. >>>>> >>>>> This morning, the gui started giving: >>>>> >>>>> IPA Error 907: NetworkError with description "cannot connect to >>>>> 'https://zsipa.private.net:443/ca/agent/ca/displayBySerial': >>>>> (SSL_ERROR_EXPIRED_CERRT_ALERT) SSL peer rejected your certificate as >>>>> expired." >>>>> >>>>> I dug into the logs and after trying to restart ipa using ipactl, there >>>>> was a >>>>> length pause, then: >>>>> >>>>> dogtag-ipa-ca-renew-agent-submit: Updated certificate not available >>>>> certmonger: Certificate named "ipaCert" in token "NSS Certificate DB" in >>>>> database "/etc/httpd/alias" is no longer valid. >>>>> dogtag-ipa-ca-renew-agent-submit: Updated certificate not available >>>>> certmonger: Certificate named "ocspSigningCert cert-pki-ca" in token "NSS >>>>> Certificate DB" in database "/etc/pki/pki-tomcat/alias" is no longer >>>>> valid. >>>>> dogtag-ipa-ca-renew-agent-submit: Updated certificate not available. >>>>> named-pkcs11[3437]: client 192.168.208.205#57832: update >>>>> '208.168.192.in-addr.arpa/IN' denied >>>>> >>>>> and then things start shutting down. I can't start ipa at all using >>>>> ipactl. >>>>> >>>>> So at present, our DNS is down. Authentication should work for a while, >>>>> but >>>>> I'd like to get this working again as quickly as possible. Any ideas? I >>>>> deal >>>>> with certificates so infrequently (like only when something like this >>>>> happens) that I'm not sure where to start. >>>>> >>>>> Thanks! >>>>> >>>>> >>>>> -- >>>>> *Bret Wortman* >>>>> /Coming soon to Kickstarter.../ >>>>> <http://wrapbuddies.co/> >>>>> http://wrapbuddies.co/ >>>>> > -- Petr Vobornik -- 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 server having cert issues
On 04/26/2016 03:26 PM, Bret Wortman wrote: > On our non-CA IPA server, this is happening, in case it's related and > illustrative: > > # ipa host-del zw113.private.net > ipa: ERROR: Certificate format error: (SEC_ERROR_LEGACY_DATABASE) The > certificate/key database is in an old, unsupported format. > # I would start with checking on all IPA servers if and what certificates are expired: # getcert list or short version to check if there are any: # getcert list | grep expires When CA cert is renewed, it is not automatically transfered to clients. There one must run: # ipa-certupdate > > On 04/26/2016 09:24 AM, Bret Wortman wrote: >> I rolled the date on the IPA server in question back to April 1 and ran >> "ipa-cacert-manage renew", which said it completed successfully. I rolled >> the >> date back to current and tried restarting ipa using ipactl stop && ipactl >> start, but no joy. No more ca renewal errors, but right after the pause I >> see >> this in /var/log/messages: >> >> systemd: kadmin.service: main process exited, code=exited, >> status=2/INVALIDARGUMENT >> systemd: Unit kadmin.service entered failed state. >> systemd: kadmin.service failed. >> >> I rebooted the server just in case, and it's still getting stuck at the same >> place. ipa-otpd doesn't get around to starting. >> >> >> Bret >> >> After the several-minutes-long pause after ipactl start outputs "Starting >> pki-tomcatd Service", I get the >> >> On 04/26/2016 08:14 AM, Bret Wortman wrote: >>> I have an IPA server on a private network which has apparently run into >>> certificate issues this morning. It's been running without issue for quite >>> a >>> while, and is on 4.1.4-1 on fedora 21. >>> >>> This morning, the gui started giving: >>> >>> IPA Error 907: NetworkError with description "cannot connect to >>> 'https://zsipa.private.net:443/ca/agent/ca/displayBySerial': >>> (SSL_ERROR_EXPIRED_CERRT_ALERT) SSL peer rejected your certificate as >>> expired." >>> >>> I dug into the logs and after trying to restart ipa using ipactl, there was >>> a >>> length pause, then: >>> >>> dogtag-ipa-ca-renew-agent-submit: Updated certificate not available >>> certmonger: Certificate named "ipaCert" in token "NSS Certificate DB" in >>> database "/etc/httpd/alias" is no longer valid. >>> dogtag-ipa-ca-renew-agent-submit: Updated certificate not available >>> certmonger: Certificate named "ocspSigningCert cert-pki-ca" in token "NSS >>> Certificate DB" in database "/etc/pki/pki-tomcat/alias" is no longer valid. >>> dogtag-ipa-ca-renew-agent-submit: Updated certificate not available. >>> named-pkcs11[3437]: client 192.168.208.205#57832: update >>> '208.168.192.in-addr.arpa/IN' denied >>> >>> and then things start shutting down. I can't start ipa at all using ipactl. >>> >>> So at present, our DNS is down. Authentication should work for a while, but >>> I'd like to get this working again as quickly as possible. Any ideas? I >>> deal >>> with certificates so infrequently (like only when something like this >>> happens) that I'm not sure where to start. >>> >>> Thanks! >>> >>> >>> -- >>> *Bret Wortman* >>> /Coming soon to Kickstarter.../ >>> <http://wrapbuddies.co/> >>> http://wrapbuddies.co/ >>> -- Petr Vobornik -- 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] concurrent requests to ipalib app giving network error
ackages/ipalib/frontend.py", line 761, in
>> run
>> return self.forward(*args, **options)
>> File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 782, in
>> forward
>> return self.Backend.rpcclient.forward(self.name <http://self.name>,
>> *args,
>> **kw)
>> File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 935, in forward
>> raise NetworkError(uri=server, error=e.errmsg)
>> ipalib.errors.NetworkError: cannot connect to
>> '<https://ipa.foo.com/ipa/json>https://ipa.foo.com/ipa/json': Internal
>> Server
>> Error
>> [pid: 5451|app: 0|req: 3/15] 10.102.235.77 () {34 vars in 463 bytes} [Thu
>> Apr
>> 21 17:43:22 2016] POST /v1/ipa/calls => generated 0 bytes in 1421 msecs
>> (HTTP/1.1 500) 0 headers in 0 bytes (0 switches on core 0)
>>
>>
>> This is how a concurrent request is being sent:
>> #!/usr/bin/env python
>>
>> from multiprocessing import Process, Pool
>> import time
>> import urllib2
>>
>> def millis():
>> return int(round(time.time() * 1000))
>>
>> def http_get(url):
>> start_time = millis()
>> request = urllib2.Request(url, headers={"Content-Type":
>> "application/json",
>> "Origin": "http://ipa.foo.com;, "Authorization": "{'token':
>> 'eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzcnYiOiJpcGEuc2F0Y2xvdWQuY29tLnRyIiwic3ViIjoiMGU1ZGZkNDc3N2I2NmNhOTU3ZTc4ZmJhZjMxNjYxMmEifQ.cr8cNy7zgQkY-q7UUyTCNPCjGlmz-LCCzUYSUV9P694'}"})
>> result = {"url": url, "data": urllib2.urlopen(request,
>> timeout=10).read()[:100]}
>> #result = {"url": url, "data": urllib2.urlopen(request, timeout=5).read()}
>> print url + " took " + str(millis() - start_time) + " ms"
>> return result
>>
>>
>> urls = ['http://api.foo.com:/v1/users',
>> 'http://api.foo.com:/v1/organizations']
>>
>> pool = Pool(processes=2)
>>
>> start_time = millis()
>> results = pool.map(http_get, urls)
>>
>> print "\nTotal took " + str(millis() - start_time) + " ms\n"
>>
>> for result in results:
>> print result
>>
>> I am confused about the reason of the error. Any idea?
>>
>>
>> --
>> Oğuz Yarımtepe
>> http://about.me/oguzy
>>
>>
>>
>
> Hello, could you check /var/logs/httpd/error_log if there is any info about
> Internal server error?
>
> It looks like there is no session cookie set (but not sure). IMO because the
> parallel processing you may need to use local instances of API instead the
> global one for each thread/process.
>
> From top of my head:
>
> api = create_api(mode=None)
> api.bootstrap()
> api.finalize()
>
>
> But I'm not sure what is the exact problem, you need try :)
>
> Martin
>
Maybe you are hitting: https://fedorahosted.org/freeipa/ticket/5653
--
Petr Vobornik
--
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
