Re: [Freeipa-users] is ipa-cert-manage safe to use?

[Rob Crittenden]

Harald Dunkel wrote:
> Hi folks,
> 
> I have to renew (or replace) the externally signed certificate
> on my ipa servers using a new ca. Apparently the tool of choice
> is ipa-cacert-manage.
> 
> Of course I found https://www.freeipa.org/page/Howto/CA_Certificate_Renewal.
> Problem is, I cannot estimate the risk and if its worth the effort.
> What happens to freeipa if ipa-cacert-manage fails miserably? Does it
> affect the LDAP database or Kerberos? Will it break the connection
> between my ipa servers or between servers and clients?
> 
> Would you suggest to forget all the "CA stuff" in freeipa and manage
> the certificates externally?
> 
> The platform of the ipa servers is Centos 7.3. There are 100+
> Debian and RedHat clients using freeipa 4.4.3 and 4.0.5 and 3.0.2.
> 
> I am highly concerned. Every helpful comment is appreciated.

I'm confused. You mention replacing some "externally signed certificate"
and yet then ask switching to externally signed certificates. What is
the current configuration? What is signing the existing server certs? Or
do you have an external CA signing the IPA CA?

ipa-cacert-manage is for managing the CA certificate, not service
certificates.

rob

-- 
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] Fresh Install of FreeIPA-Server - CentOS7

[Rob Crittenden]

Robert L. Harris wrote:
> 
> Hmmm
> 
> {0}:/var/log>ls
> anaconda  btmp  dmesg  grubby  maillog   pppsecure  
> tallylog  wtmp
> audit cron  dmesg.old  grubby_prune_debug  messages  rhsm   spooler
>  tuned yum.log
> boot.log  cups  firewalld  lastlog ntpstats  samba  sssd
> vmware-vmsvc.log
> 
> 
> root@ipa
> {1}:/var/log>rpm -q -l http
> package http is not installed
> 
> root@ipa
> {1}:/var/log>rpm -q -a | grep -i http
> perl-HTTP-Tiny-0.033-3.el7.noarch
> 
> root@ipa
> {0}:/var/log>rpm -q -a | grep -i tomcat
> 
> 
> Doesn't look like an httpd was installed as a dependancy?

I find this very hard to believe given that it go so far as to configure
things in Apache, restart it, etc. What version of [free]ipa-server is
installed? How did you install it and from what repo?

rob

> 
> 
> 
> 
> 
> On Fri, May 12, 2017 at 1:17 AM Martin Bašti  > wrote:
> 
> That's weird, it should be super fast, anything in
> /var/log/httpd/error_log?
> 
> 
> On 11.05.2017 22:23, Robert L. Harris wrote:
>>
>> Odd, must have clicked reply instead of reply-all.
>>
>> Anyway, I did the revert and re-install.  Actual install went
>> through fine then the "ipa-server-install" ran until this:
>>
>>   [8/9]: restoring configuration
>>   [9/9]: starting directory server
>> Done.
>> Restarting the directory server
>> Restarting the KDC
>> Please add records in this file to your DNS system:
>> /tmp/ipa.system.records.v5Jwrt.db
>> Restarting the web server
>> Configuring client side components
>> Using existing certificate '/etc/ipa/ca.crt'.
>> Client hostname: ipa.rdlg.net 
>> Realm: RDLG.NET 
>> DNS Domain: rdlg.net 
>> IPA Server: ipa.rdlg.net 
>> BaseDN: dc=rdlg,dc=net
>>
>> Skipping synchronizing time with NTP server.
>> New SSSD config will be created
>> Configured sudoers in /etc/nsswitch.conf
>> Configured /etc/sssd/sssd.conf
>> trying https://ipa.rdlg.net/ipa/json
>> Forwarding 'schema' to json server 'https://ipa.rdlg.net/ipa/json'
>>
>>
>> It's been sitting there for a while ( 4 hours? )  I don't see
>> anyting in the ipaserver-install.log, but it's here:
>>  https://pastebin.com/biK1Dmv7
>>
>>
>>
>> On Thu, May 11, 2017 at 8:12 AM Martin Bašti > > wrote:
>>
>> Please keep freeipa-users in CC
>>
>> Snapshot is always better, so I suggest to use it. Otherwise
>> there is an option --ignore-last-of-role to unblock
>> uninstallation.
>>
>> Martin
>>
>>
>> On 11.05.2017 16:00, Robert L. Harris wrote:
>>>
>>> Looks like you hit it, apache didn't have a group:
>>>
>>> -- Logs begin at Wed 2017-05-10 19:56:27 MDT, end at Thu
>>> 2017-05-11 07:48:27 MDT. --
>>> May 10 20:36:00 ipa.rdlg.net 
>>> systemd[1]: Starting The Apache HTTP Server...
>>> May 10 20:36:00 ipa.rdlg.net 
>>> ipa-httpd-kdcproxy[28808]: ipa : INFO KDC proxy
>>> enabled
>>> May 10 20:36:00 ipa.rdlg.net 
>>> httpd[28809]: AH00544: httpd: bad group name apache
>>> May 10 20:36:00 ipa.rdlg.net 
>>> systemd[1]: httpd.service: main process exited, code=exited,
>>> status=1/FAILURE
>>> May 10 20:36:00 ipa.rdlg.net 
>>> kill[28812]: kill: cannot find process ""
>>> May 10 20:36:00 ipa.rdlg.net 
>>> systemd[1]: httpd.service: control process exited,
>>> code=exited status=1
>>> May 10 20:36:00 ipa.rdlg.net 
>>> systemd[1]: Failed to start The Apache HTTP Server.
>>> May 10 20:36:00 ipa.rdlg.net 
>>> systemd[1]: Unit httpd.service entered failed state.
>>> May 10 20:36:00 ipa.rdlg.net 
>>> systemd[1]: httpd.service failed.
>>>
>>> Thanks, didn't know that command.  I tried to continue the
>>> process:
>>>
>>> {0}:/root>ipa-server-install
>>>
>>> The log file for this installation can be found in
>>> /var/log/ipaserver-install.log
>>> ipa.ipapython.install.cli.install_tool(Server): ERRORIPA
>>> server is already configured on this system.
>>> If you want to reinstall the IPA server, please uninstall it
>>> first using 'ipa-server-install --uninstall'.
>>> ipa.ipapython.install.cli.install_tool(Server): ERRORThe
>>> ipa-server-install command failed. See
>>> /var/log/ipaserver-install.log for more information
>>>
>>> root@ipa
>>> {1}:/root>ipa-server-install  --uninstall
>>>
>>>  

Re: [Freeipa-users] Web UI unavailable after 4.4 upgrade - 400 error

[Rob Crittenden]

ion: 0:20:00
> [Mon May 08 10:59:16.497682 2017] [:error] [pid 26013] ipa: DEBUG:
> SessionAuthManager.register: name=xmlserver_session_139942843997200
> [Mon May 08 10:59:16.498514 2017] [:error] [pid 26013] ipa: DEBUG:
> SessionAuthManager.register: name=jsonserver_session_139942844019152
> [Mon May 08 10:59:16.582967 2017] [:error] [pid 26013] ipa: DEBUG:
> Mounting ipaserver.rpcserver.login_password() at '/session/login_password'
> [Mon May 08 10:59:16.583114 2017] [:error] [pid 26013] ipa: DEBUG:
> session_auth_duration: 0:20:00
> [Mon May 08 10:59:17.103275 2017] [:error] [pid 26014] ipa: DEBUG:
> Mounting ipaserver.rpcserver.sync_token() at '/session/sync_token'
> [Mon May 08 10:59:17.148714 2017] [:error] [pid 26014] ipa: DEBUG:
> Mounting ipaserver.rpcserver.change_password() at '/session/change_password'
> [Mon May 08 10:59:17.234845 2017] [:error] [pid 26013] ipa: DEBUG:
> Mounting ipaserver.rpcserver.sync_token() at '/session/sync_token'
> [Mon May 08 10:59:17.280518 2017] [:error] [pid 26013] ipa: DEBUG:
> Mounting ipaserver.rpcserver.change_password() at '/session/change_password'
> [Mon May 08 10:59:17.397722 2017] [:error] [pid 26014] ipa: DEBUG:
> Mounting ipaserver.rpcserver.xmlserver_session() at '/session/xml'
> [Mon May 08 10:59:17.397862 2017] [:error] [pid 26014] ipa: DEBUG:
> session_auth_duration: 0:20:00
> [Mon May 08 10:59:17.397953 2017] [:error] [pid 26014] ipa: DEBUG:
> session_auth_duration: 0:20:00
> [Mon May 08 10:59:17.504097 2017] [:error] [pid 26014] ipa: DEBUG:
> Mounting ipaserver.rpcserver.login_kerberos() at '/session/login_kerberos'
> [Mon May 08 10:59:17.504234 2017] [:error] [pid 26014] ipa: DEBUG:
> session_auth_duration: 0:20:00
> [Mon May 08 10:59:17.531236 2017] [:error] [pid 26013] ipa: DEBUG:
> Mounting ipaserver.rpcserver.xmlserver_session() at '/session/xml'
> [Mon May 08 10:59:17.531357 2017] [:error] [pid 26013] ipa: DEBUG:
> session_auth_duration: 0:20:00
> [Mon May 08 10:59:17.531447 2017] [:error] [pid 26013] ipa: DEBUG:
> session_auth_duration: 0:20:00
> [Mon May 08 10:59:17.602015 2017] [:error] [pid 26014] ipa: DEBUG:
> Mounting ipaserver.rpcserver.login_x509() at '/session/login_x509'
> [Mon May 08 10:59:17.602158 2017] [:error] [pid 26014] ipa: DEBUG:
> session_auth_duration: 0:20:00
> [Mon May 08 10:59:17.638029 2017] [:error] [pid 26013] ipa: DEBUG:
> Mounting ipaserver.rpcserver.login_kerberos() at '/session/login_kerberos'
> [Mon May 08 10:59:17.638166 2017] [:error] [pid 26013] ipa: DEBUG:
> session_auth_duration: 0:20:00
> [Mon May 08 10:59:17.665313 2017] [:error] [pid 26014] ipa: DEBUG:
> Mounting ipaserver.rpcserver.xmlserver() at '/xml'
> [Mon May 08 10:59:17.665430 2017] [:error] [pid 26014] ipa: DEBUG:
> session_auth_duration: 0:20:00
> [Mon May 08 10:59:17.736510 2017] [:error] [pid 26013] ipa: DEBUG:
> Mounting ipaserver.rpcserver.login_x509() at '/session/login_x509'
> [Mon May 08 10:59:17.736656 2017] [:error] [pid 26013] ipa: DEBUG:
> session_auth_duration: 0:20:00
> [Mon May 08 10:59:17.737976 2017] [:error] [pid 26014] ipa: DEBUG:
> Mounting ipaserver.rpcserver.jsonserver_session() at '/session/json'
> [Mon May 08 10:59:17.738089 2017] [:error] [pid 26014] ipa: DEBUG:
> session_auth_duration: 0:20:00
> [Mon May 08 10:59:17.799767 2017] [:error] [pid 26013] ipa: DEBUG:
> Mounting ipaserver.rpcserver.xmlserver() at '/xml'
> [Mon May 08 10:59:17.799902 2017] [:error] [pid 26013] ipa: DEBUG:
> session_auth_duration: 0:20:00
> [Mon May 08 10:59:17.800287 2017] [:error] [pid 26014] ipa: DEBUG:
> Mounting ipaserver.rpcserver.jsonserver_kerb() at '/json'
> [Mon May 08 10:59:17.800404 2017] [:error] [pid 26014] ipa: DEBUG:
> session_auth_duration: 0:20:00
> [Mon May 08 10:59:17.872938 2017] [:error] [pid 26013] ipa: DEBUG:
> Mounting ipaserver.rpcserver.jsonserver_session() at '/session/json'
> [Mon May 08 10:59:17.873074 2017] [:error] [pid 26013] ipa: DEBUG:
> session_auth_duration: 0:20:00
> [Mon May 08 10:59:17.935616 2017] [:error] [pid 26013] ipa: DEBUG:
> Mounting ipaserver.rpcserver.jsonserver_kerb() at '/json'
> [Mon May 08 10:59:17.935746 2017] [:error] [pid 26013] ipa: DEBUG:
> session_auth_duration: 0:20:00
> [Mon May 08 10:59:18.179768 2017] [:error] [pid 26014] ipa: INFO: ***
> PROCESS START ***
> [Mon May 08 10:59:18.313005 2017] [:error] [pid 26013] ipa: INFO: ***
> PROCESS START ***
> 
> 
> 
>> On May 8, 2017, at 1:57 PM, Rob Crittenden <rcrit...@redhat.com
>> <mailto:rcrit...@redhat.com>> wrote:
>>
>> Pete Fuller wrote:
>>> http error log has nothing.  This is with http restart and a failed
>>> request for web ui.  The request has no error.  Is there a different log
>>> that I am overlooking that might have more information?
>>
>>

Re: [Freeipa-users] sudo (sssd) hangs due to ipa install/uninstall scripts

[Rob Crittenden]

Prasun Gera wrote:
> Just writing to say that the automount scripts still seem to be quite
> broken in RHEL 7.3. I did a couple of client installs recently,
> and ipa-client-automount --install completed successfully, but didn't
> add sss to /etc/nsswitch.conf. By now, I've got used to this pattern. So
> I look for the presence or absence of sss in nsswitch.conf after running
> any of these scripts, since that seems to be the most common issue.

https://bugzilla.redhat.com/show_bug.cgi?id=1392540

rob

> 
> On Thu, Sep 3, 2015 at 3:17 AM, Alexander Bokovoy  > wrote:
> 
> On Wed, 02 Sep 2015, Prasun Gera wrote:
> 
> I have zero confidence in any of the install and uninstall
> scripts. And
> this is on RHEL systems. On unofficial ones like Ubuntu, things
> are even
> more broken. I really like freeipa, but so far even in a
> smallish lab
> environment, it has been a nightmare. I am really tempted to
> just go back
> to NIS. Does anyone have any ideas or proposals for making
> things more
> robust ? At the very least, I think that these sort of
> modifications to
> system files should only happen with package install/removal.
> Any changes
> that ipa's scripts do should be local to ipa's internal state.
> Better would
> be to have an internal ipa database sort of thing which keeps
> track of what
> the current state is so that even if a script dies, which has
> happened
> often, the next attempt reads the database and figures out what
> happened
> earlier.
> 
> File bugs with enough details. It is the only reliable way to fix any
> issues where environments differ. Install/uninstall scripts work for
> fresh installs in RHEL and Fedora because this is what is tested. If you
> have repurposed machines from some other setups, things might differ and
> only you know what is in your environment.
> 
> That's not bad or good, that's just different -- the more different
> environments we see, more robust code can be added. People are
> infinitely more clever than computers when it comes to configuration
> files' format mangling.
> 
> I've seen multiple cases where a claim of 'ipa scripts broke my
> configuration' was later retracted saying that puppet or other SCM run
> afterwards did these changes. That just happen, if there are many
> elephants dancing in the room, a careful coordination is always a good
> idea.
> 
> Coming back to your issues, please file bugs -- either upstream or
> downstream, via distributions, whatever way is more suitable to you.
> Contributing 'broken' config files would be good too.
> 
> 
> -- 
> / Alexander Bokovoy
> 
> 
> 
> 

-- 
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 unavailable after 4.4 upgrade - 400 error

[Rob Crittenden]

Pete Fuller wrote:
> http error log has nothing.  This is with http restart and a failed
> request for web ui.  The request has no error.  Is there a different log
> that I am overlooking that might have more information?

No.

Create /etc/ipa/server.conf with these contents:

[global]
debug = True

Restart Apache.

Try with a browser and see what gets logged, if anything.

I'd also try with the cli to compare. With the client you can add -vvv
to get a lot more client-side logging: ipa -vvv user-show admin

rob

> 
> 
> [Mon May 08 10:46:14.842162 2017] [:warn] [pid 25471]
> NSSSessionCacheTimeout is deprecated. Ignoring.
> [Mon May 08 10:46:15.136803 2017] [auth_digest:notice] [pid 25471]
> AH01757: generating secret for digest authentication ...
> [Mon May 08 10:46:15.137403 2017] [lbmethod_heartbeat:notice] [pid
> 25471] AH02282: No slotmem from mod_heartmonitor
> [Mon May 08 10:46:15.137422 2017] [:warn] [pid 25471]
> NSSSessionCacheTimeout is deprecated. Ignoring.
> [Mon May 08 10:46:15.145343 2017] [mpm_prefork:notice] [pid 25471]
> AH00163: Apache/2.4.6 (CentOS) mod_auth_gssapi/1.4.0 mod_auth_kerb/5.4
> mod_nss/1.0.14 NSS/3.21 Basic ECC mod_wsgi/3.4 Python/2.7.5 configured
> -- resuming normal operations
> [Mon May 08 10:46:15.145378 2017] [core:notice] [pid 25471] AH00094:
> Command line: '/usr/sbin/httpd -D FOREGROUND'
> [Mon May 08 10:46:18.234880 2017] [:error] [pid 25476] ipa: INFO: ***
> PROCESS START ***
> [Mon May 08 10:46:18.431700 2017] [:error] [pid 25475] ipa: INFO: ***
> PROCESS START **
> 
> 
> 
>> On May 8, 2017, at 1:43 PM, Rob Crittenden <rcrit...@redhat.com
>> <mailto:rcrit...@redhat.com>> wrote:
>>
>> Pete Fuller wrote:
>>> IPA command line seems to work.   Have been able to use ipa user-find
>>> and ipa cert-find.  Can also sudo and kinit from other machines as
>>> IPA user.
>>>
>>> Another clue here, looks like even when querying with the ipa cli tools,
>>> I’m getting 400 errors in the access logs.  The top one is obviously a
>>> browser request.  The next 4 were following a cli call to ipa user-find.
>>> That request does respond back with users, so not sure what is failing
>>> there.  The 192.168.0.95 IP is the local ip of the IPA server itself. 
>>>
>>> 192.168.51.20 - - [08/May/2017:10:31:46 -0700] "GET / HTTP/1.1" 400 347
>>> "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:53.0)
>>> Gecko/20100101 Firefox/53.0"
>>> 192.168.0.95 - - [08/May/2017:10:32:40 -0700] "POST /ipa/json HTTP/1.1"
>>> 400 347
>>> 192.168.0.95 - - [08/May/2017:10:32:43 -0700] "POST /ipa/json HTTP/1.1"
>>> 400 347
>>> 192.168.0.95 - - [08/May/2017:10:33:01 -0700] "POST /ipa/json HTTP/1.1"
>>> 400 347
>>> 192.168.0.95 - - [08/May/2017:10:33:10 -0700] "POST /ipa/json HTTP/1.1"
>>> 400 347
>>
>> Note that client activity (login, sudo, etc) does not go through Apache.
>> Only the IPA API does (so web UI and cli).
>>
>> Still need to see the error log.
>>
>> rob
>>
>>>
>>>
>>>> On May 8, 2017, at 1:20 PM, Rob Crittenden <rcrit...@redhat.com
>>>> <mailto:rcrit...@redhat.com>
>>>> <mailto:rcrit...@redhat.com>> wrote:
>>>>
>>>> Pete Fuller wrote:
>>>>> I ran the 4.4 upgrade yesterday on a group of Centos7 servers that are
>>>>> IPA replicas for my North American datacenters.  All seem to have the
>>>>> same issue that I am now unable to connect to the web UI, with the
>>>>> following error in the browser…
>>>>>
>>>>>
>>>>> Bad Request
>>>>>
>>>>> Your browser sent a request that this server could not understand.
>>>>>
>>>>> Additionally, a 400 Bad Request error was encountered while trying to
>>>>> use an ErrorDocument to handle the request.
>>>>>
>>>>>
>>>>>
>>>>> The maddening thing is I can’t find any reference in the apache logs to
>>>>> what is generating the error and why a direct request to the UI would
>>>>> error. 
>>>>>
>>>>> As far as I can tell IPA is otherwise working.  Logins seem to work,
>>>>> sudo rules are working, DNS is working.  
>>>>>
>>>>> [root@lb3 httpd]# ipactl status
>>>>> Directory Service: RUNNING
>>>>> krb5kdc Service: RUNNING
>>>>> kadmin Service: RUNNING
>>>>> named Service: RUNNING
>>>>> ipa_memcached Service: RUNNING
>>>>> httpd Service: RUNNING
>>>>> ipa-custodia Service: RUNNING
>>>>> ntpd Service: RUNNING
>>>>> pki-tomcatd Service: RUNNING
>>>>> ipa-otpd Service: RUNNING
>>>>> ipa-dnskeysyncd Service: RUNNING
>>>>>
>>>>> I can see one file in the httpd/conf.d directory that was changed -
>>>>> nss.conf.  I attempted reverting and that did not work.
>>>>>
>>>>> Has anyone run upon this error?  
>>>>
>>>> Does the ipa command-line tool work?
>>>>
>>>> What are you seeing in the Apache error log?
>>>>
>>>> rob
> 

-- 
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 unavailable after 4.4 upgrade - 400 error

[Rob Crittenden]

Pete Fuller wrote:
> IPA command line seems to work.   Have been able to use ipa user-find
> and ipa cert-find.  Can also sudo and kinit from other machines as IPA user.
> 
> Another clue here, looks like even when querying with the ipa cli tools,
> I’m getting 400 errors in the access logs.  The top one is obviously a
> browser request.  The next 4 were following a cli call to ipa user-find.
>  That request does respond back with users, so not sure what is failing
> there.  The 192.168.0.95 IP is the local ip of the IPA server itself. 
> 
> 192.168.51.20 - - [08/May/2017:10:31:46 -0700] "GET / HTTP/1.1" 400 347
> "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:53.0)
> Gecko/20100101 Firefox/53.0"
> 192.168.0.95 - - [08/May/2017:10:32:40 -0700] "POST /ipa/json HTTP/1.1"
> 400 347
> 192.168.0.95 - - [08/May/2017:10:32:43 -0700] "POST /ipa/json HTTP/1.1"
> 400 347
> 192.168.0.95 - - [08/May/2017:10:33:01 -0700] "POST /ipa/json HTTP/1.1"
> 400 347
> 192.168.0.95 - - [08/May/2017:10:33:10 -0700] "POST /ipa/json HTTP/1.1"
> 400 347

Note that client activity (login, sudo, etc) does not go through Apache.
Only the IPA API does (so web UI and cli).

Still need to see the error log.

rob

> 
> 
>> On May 8, 2017, at 1:20 PM, Rob Crittenden <rcrit...@redhat.com
>> <mailto:rcrit...@redhat.com>> wrote:
>>
>> Pete Fuller wrote:
>>> I ran the 4.4 upgrade yesterday on a group of Centos7 servers that are
>>> IPA replicas for my North American datacenters.  All seem to have the
>>> same issue that I am now unable to connect to the web UI, with the
>>> following error in the browser…
>>>
>>>
>>>  Bad Request
>>>
>>> Your browser sent a request that this server could not understand.
>>>
>>> Additionally, a 400 Bad Request error was encountered while trying to
>>> use an ErrorDocument to handle the request.
>>>
>>>
>>>
>>> The maddening thing is I can’t find any reference in the apache logs to
>>> what is generating the error and why a direct request to the UI would
>>> error. 
>>>
>>> As far as I can tell IPA is otherwise working.  Logins seem to work,
>>> sudo rules are working, DNS is working.  
>>>
>>> [root@lb3 httpd]# ipactl status
>>> Directory Service: RUNNING
>>> krb5kdc Service: RUNNING
>>> kadmin Service: RUNNING
>>> named Service: RUNNING
>>> ipa_memcached Service: RUNNING
>>> httpd Service: RUNNING
>>> ipa-custodia Service: RUNNING
>>> ntpd Service: RUNNING
>>> pki-tomcatd Service: RUNNING
>>> ipa-otpd Service: RUNNING
>>> ipa-dnskeysyncd Service: RUNNING
>>>
>>> I can see one file in the httpd/conf.d directory that was changed -
>>> nss.conf.  I attempted reverting and that did not work.
>>>
>>> Has anyone run upon this error?  
>>
>> Does the ipa command-line tool work?
>>
>> What are you seeing in the Apache error log?
>>
>> rob
> 

-- 
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 unavailable after 4.4 upgrade - 400 error

[Rob Crittenden]

Pete Fuller wrote:
> I ran the 4.4 upgrade yesterday on a group of Centos7 servers that are
> IPA replicas for my North American datacenters.  All seem to have the
> same issue that I am now unable to connect to the web UI, with the
> following error in the browser…
> 
> 
>   Bad Request
> 
> Your browser sent a request that this server could not understand.
> 
> Additionally, a 400 Bad Request error was encountered while trying to
> use an ErrorDocument to handle the request.
> 
> 
> 
> The maddening thing is I can’t find any reference in the apache logs to
> what is generating the error and why a direct request to the UI would
> error. 
> 
> As far as I can tell IPA is otherwise working.  Logins seem to work,
> sudo rules are working, DNS is working.  
> 
> [root@lb3 httpd]# ipactl status
> Directory Service: RUNNING
> krb5kdc Service: RUNNING
> kadmin Service: RUNNING
> named Service: RUNNING
> ipa_memcached Service: RUNNING
> httpd Service: RUNNING
> ipa-custodia Service: RUNNING
> ntpd Service: RUNNING
> pki-tomcatd Service: RUNNING
> ipa-otpd Service: RUNNING
> ipa-dnskeysyncd Service: RUNNING
> 
> I can see one file in the httpd/conf.d directory that was changed -
> nss.conf.  I attempted reverting and that did not work.
> 
> Has anyone run upon this error?  

Does the ipa command-line tool work?

What are you seeing in the Apache error log?

rob

-- 
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] Could not connect to LDAP server host - IO Error creating JSS SSL Socket:

[Rob Crittenden]

Michael Plemmons wrote:
> I just realized that I sent the reply directly to Rob and not to the
> list.  My response is inline

Ok, this is actually good news.

I made a similar proposal in another case and I was completely wrong.
Flo had the user do something and it totally fixed their auth error, I
just can't remember what it was or find the e-mail thread. I'm pretty
sure it was this calendar year though.

rob

> 
> 
> 
> *Mike Plemmons | Senior DevOps Engineer | CROSSCHX
> *
> 614.427.2411
> mike.plemm...@crosschx.com <mailto:mike.plemm...@crosschx.com>
> www.crosschx.com <http://www.crosschx.com/>
> 
> On Thu, May 4, 2017 at 9:39 AM, Michael Plemmons
> <michael.plemm...@crosschx.com <mailto:michael.plemm...@crosschx.com>>
> wrote:
> 
> 
> 
> 
> 
> *Mike Plemmons | Senior DevOps Engineer | CROSSCHX
> *
> 614.427.2411
> mike.plemm...@crosschx.com <mailto:mike.plemm...@crosschx.com>
>     www.crosschx.com <http://www.crosschx.com/>
> 
> On Thu, May 4, 2017 at 9:24 AM, Rob Crittenden <rcrit...@redhat.com
> <mailto:rcrit...@redhat.com>> wrote:
> 
> Michael Plemmons wrote:
> > I realized that I was not very clear in my statement about
> testing with
> > ldapsearch.  I had initially run it without logging in with a
> DN.  I was
> > just running the local ldapsearch -x command.  I then tested on
> > ipa12.mgmt and ipa11.mgmt logging in with a full DN for the
> admin and
> > "cn=Directory Manager" from ipa12.mgmt (broken server) and
> ipa11.mgmt
> > and both ldapsearch command succeeded.
> >
> > I ran the following from ipa12.mgmt and ipa11.mgmt as a non
> root user.
> > I also ran the command showing a line count for the output and
> the line
> > counts for each were the same when run from ipa12.mgmt and
> ipa11.mgmt.
> >
> > ldapsearch -LLL -h ipa12.mgmt.crosschx.com
> <http://ipa12.mgmt.crosschx.com>
> > <http://ipa12.mgmt.crosschx.com
> <http://ipa12.mgmt.crosschx.com>> -D "DN" -w PASSWORD -b
> > "cn=users,cn=accounts,dc=mgmt,dc=crosschx,dc=com" dn
> >
> > ldapsearch -LLL -h ipa12.mgmt.crosschx.com
> <http://ipa12.mgmt.crosschx.com>
> > <http://ipa12.mgmt.crosschx.com
> <http://ipa12.mgmt.crosschx.com>> -D "cn=directory manager" -w
> PASSWORD dn
> 
> The CA has its own suffix and replication agreements. Given the auth
> error and recent (5 months) renewal of CA credentials I'd check
> that the
> CA agent authentication entries are correct.
> 
> Against each master with a CA run:
> 
> $ ldapsearch -LLL -x -D 'cn=directory manager' -W -b
> uid=ipara,ou=people,o=ipaca description
> 
> The format is 2;serial#,subject,issuer
> 
> Then on each run:
> 
> # certutil -L -d /etc/httpd/alias -n ipaCert |grep Serial
> 
> The serial # should match that in the description everywhere.
> 
> rob
> 
> 
> 
> On the CA (IPA13.MGMT) I ran the ldapsearch command and see that the
> serial number is 7.  I then ran the certutil command on all three
> servers and the serial number is 7 as well.
> 
>  
> I also ran the ldapsearch command against the other two servers and
> they also showed a serial number of 7. 
> 
>  
> 
> 
> >
> >
> >
> >
> >
> > *Mike Plemmons | Senior DevOps Engineer | CROSSCHX
> > *
> > 614.427.2411
> > mike.plemm...@crosschx.com <mailto:mike.plemm...@crosschx.com>
> <mailto:mike.plemm...@crosschx.com
> <mailto:mike.plemm...@crosschx.com>>
> > www.crosschx.com <http://www.crosschx.com>
> <http://www.crosschx.com/>
> >
> > On Wed, May 3, 2017 at 5:28 PM, Michael Plemmons
> > <michael.plemm...@crosschx.com
> <mailto:michael.plemm...@crosschx.com>
> <mailto:michael.plemm...@crosschx.com
> <mailto:michael.plemm...@crosschx.com>>>
> > wrote:
> >
> > I have a three node IPA cluster.
> >
> > ipa11.mgmt - was a master over 6 months ago
> > ipa13.mgmt - current master
> > ipa12.mgmt

Re: [Freeipa-users] how to setup freeipa project to local environment

[Rob Crittenden]

rajkumar wrote:
> Hello freeipa team,
> 
> I have download freeipa4.4.4.tar.gz and I need to setup  freeipa project
> as a local environment(to customize via IDE like eclipse) for
> customization. suggest me how can do that. or any reference link.

I'd start with the BUILD file in the tree.

rob

-- 
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] Need LDAP access for host not in IPA domain

[Rob Crittenden]

Detlev Habicht wrote:
> Hello,
> 
> i need a simple, plain LDAP bind for authentication for a host,
> which is not part of my IPA domain.
> 
> Something like this is working in the domain:
> 
>  ldapsearch -vx -H ldaps://xxx.yyy.intern -b "cn=accounts,dc=yyy,dc=intern"
> 
> My problem is, it is only working with the hostname xxx.yyy.intern which
> is part of my domain yyy.intern. But outside of the domain i have to
> use the IP address or something like xxx.yyy.zzz.de
>  .
> 
> But than i have this error message:
> 
> ldap_initialize( ldaps://xxx.yyy.zzz.de:636/??base )
> ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
> 
> Any idea what i can do?
> 
> Thank you!
> 
> Detlev
> 
> P.S.: I have the same problem in the domain, when i am not using 
>   xxx.yyy.intern. IP address for example is also not working.

I'd slap a -d 255 onto that command. It will give you a lot more
information on what is going on. It could be rejecting the request
because the requested name (IP address) doesn't match anything in the cert.

The 389-ds access log will also confirm whether you are making a
connection or not (to rule out firewall, etc). Note that this log is
buffered so you need to be patient, tail -f won't show connections
immediately.

rob

-- 
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] Could not connect to LDAP server host - IO Error creating JSS SSL Socket:

[Rob Crittenden]

Michael Plemmons wrote:
> I realized that I was not very clear in my statement about testing with
> ldapsearch.  I had initially run it without logging in with a DN.  I was
> just running the local ldapsearch -x command.  I then tested on
> ipa12.mgmt and ipa11.mgmt logging in with a full DN for the admin and
> "cn=Directory Manager" from ipa12.mgmt (broken server) and ipa11.mgmt
> and both ldapsearch command succeeded. 
> 
> I ran the following from ipa12.mgmt and ipa11.mgmt as a non root user. 
> I also ran the command showing a line count for the output and the line
> counts for each were the same when run from ipa12.mgmt and ipa11.mgmt.
> 
> ldapsearch -LLL -h ipa12.mgmt.crosschx.com
>  -D "DN" -w PASSWORD -b
> "cn=users,cn=accounts,dc=mgmt,dc=crosschx,dc=com" dn
> 
> ldapsearch -LLL -h ipa12.mgmt.crosschx.com
>  -D "cn=directory manager" -w PASSWORD dn

The CA has its own suffix and replication agreements. Given the auth
error and recent (5 months) renewal of CA credentials I'd check that the
CA agent authentication entries are correct.

Against each master with a CA run:

$ ldapsearch -LLL -x -D 'cn=directory manager' -W -b
uid=ipara,ou=people,o=ipaca description

The format is 2;serial#,subject,issuer

Then on each run:

# certutil -L -d /etc/httpd/alias -n ipaCert |grep Serial

The serial # should match that in the description everywhere.

rob

> 
> 
> 
> 
> 
> *Mike Plemmons | Senior DevOps Engineer | CROSSCHX
> *
> 614.427.2411
> mike.plemm...@crosschx.com 
> www.crosschx.com 
> 
> On Wed, May 3, 2017 at 5:28 PM, Michael Plemmons
> >
> wrote:
> 
> I have a three node IPA cluster.
> 
> ipa11.mgmt - was a master over 6 months ago
> ipa13.mgmt - current master
> ipa12.mgmt
> 
> ipa13 has agreements with ipa11 and ipa12.  ipa11 and ipa12 do not
> have agreements between each other.
> 
> It appears that either ipa12.mgmt lost some level of its replication
> agreement with ipa13.  I saw some level because users / hosts were
> replicated between all systems but we started seeing DNS was not
> resolving properly from ipa12.  I do not know when this started.
> 
> When looking at replication agreements on ipa12 I did not see any
> agreement with ipa13.
> 
> When I run ipa-replica-manage list all three hosts show has master.
> 
> When I run ipa-replica-manage ipa11.mgmt I see ipa13.mgmt is a replica.
> 
> When I run ipa-replica-manage ipa12.mgmt nothing returned.
> 
> I ran ipa-replica-manage connect --cacert=/etc/ipa/ca.crt
> ipa12.mgmt.crosschx.com 
> ipa13.mgmt.crosschx.com  on ipa12.mgmt
> 
> I then ran the following
> 
> ipa-replica-manage force-sync --from ipa13.mgmt.crosschx.com
> 
> 
> ipa-replica-manage re-initialize --from ipa13.mgmt.crosschx.com
> 
> 
> I was still seeing bad DNS returns when dig'ing against ipa12.mgmt. 
> I was able to create user and DNS records and see the information
> replicated properly across all three nodes.
> 
> I then ran ipactl stop on ipa12.mgmt and then ipactl start on
> ipa12.mgmt because I wanted to make sure everything was running
> fresh after the changes above.  While IPA was staring up (DNS
> started) we were able to see valid DNS queries returned but
> pki-tomcat would not start.
> 
> I am not sure what I need to do in order to get this working.  I
> have included the output of certutil and getcert below from all
> three servers as well as the debug output for pki.
> 
> 
> While the IPA system is coming up I am able to successfully run
> ldapsearch -x as the root user and see results.  I am also able to
> login with the "cn=Directory Manager" account and see results.
> 
> 
> The debug log shows the following error.
> 
> 
> [03/May/2017:21:22:01][localhost-startStop-1]:
> 
> [03/May/2017:21:22:01][localhost-startStop-1]: =  DEBUG
> SUBSYSTEM INITIALIZED   ===
> [03/May/2017:21:22:01][localhost-startStop-1]:
> 
> [03/May/2017:21:22:01][localhost-startStop-1]: CMSEngine: restart at
> autoShutdown? false
> [03/May/2017:21:22:01][localhost-startStop-1]: CMSEngine:
> autoShutdown crumb file path?
> /var/lib/pki/pki-tomcat/logs/autoShutdown.crumb
> [03/May/2017:21:22:01][localhost-startStop-1]: CMSEngine: about to
> look for cert for auto-shutdown support:auditSigningCert cert-pki-ca
> [03/May/2017:21:22:01][localhost-startStop-1]: CMSEngine: found
> cert:auditSigningCert cert-pki-ca
> [03/May/2017:21:22:01][localhost-startStop-1]: CMSEngine: 

Re: [Freeipa-users] ipa server-del

[Rob Crittenden]

Petr Vobornik wrote:
> 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
> 

I think it is probably a replication conflict entry. I'd start with
https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/8.2/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html

rob

-- 
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] External cert with correct CSR?

[Rob Crittenden]

Kat wrote:
> Hi all,
> 
> I am somewhat confused trying to get the process of using an external
> cert for IPA.
> 
> If I follow step 1:
> ipa-server-install -a Secret123 -p Secret123 -r EXAMPLE.COM
> --external-ca -U
> 
> This does indeed generate a CSR, but trying to do anything with this CSR
> has no success since it is not properly formed with all info.  In
> otherwords, ipa does not add country, state, location, etc. If I submit
> this CSR to any cert company, it will of course, complain. Is there a
> way to get this right? Or am I just missing something here?
> 

What cert company are you trying to get to sign this? This is a CA cert,
I don't know that any of the major ones will sign this, at least not
without a huge check.

What version of IPA?

rob

-- 
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] EL5 sudo and IdM

[Rob Crittenden]

Z D wrote:
> Hi, we've been using the IdM server 4.4.0 but still have some EL5 (build
> system) we'd like to be ipa-clients. The ipa-client v2.1.3 has been
> installed, that works well. 
> 
> And I believe that with EL5, there is no sssd support for sudo, hence
> it's configured via /etc/ldap.conf
> 
> 
> The situation I see is that sudo rule is successful only when using ALL
> for hosts, the example of debug message is: 
> 
> sudo: ldap sudoHost 'ALL' ... MATCH! 
> 
> 
> Otherwise, it doesn't work and the message is:
> 
> sudo: ldap sudoHost '+hostg_build' ... not 
> 
> 
> The "hostg_build" is IPA host group, and if I read "man sudoers.ldap"
> correctly, sudoHost expects host netgroup (prefixed with a |'+'|). 

A netgroup is created for every hostgroup automatically. Make sure you
have your NIS domain set and the netgroup is resolvable using getent
netgroup foo

rob

-- 
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] Help needed - CA Server role not adding

[Rob Crittenden]

Chris Moody wrote:
> Hello.
> 
> First wanted to thank everyone working hard to bring this awesome bundle
> of applications to market.  This is a great project and I really
> appreciate the efforts.
> 
> I need a hand with a new 4.4.3 install that I'm still trying to flesh
> out fully to support all the services I need.
> 
> I recently attempted to add the 'CA Server' Role to a node in a replica
> pair.
> 
> I ran the 'ipa-ca-install' command on the node in question but in the
> middle of the operation, it unfortunately bombed out due to memory
> exhaustion.  I have since doubled the RAM in the host, but I can no
> longer get this system to proceed with the multitude of steps it
> performs to enable this role.
> 
> When I type 'ipa server-role-find' it lists the 'CA Server' Role as
> absent, but whenever I issue the command 'ipa-ca-install' to try and
> re-instantiate the process of adding the role, it spits back out 'CA is
> already installed on this host.'.
> 
> I'm not seeing a 'remove role' or 'force' option via any of the
> tab-completed command options now available in 4.x nor is the man page
> of much help.  Online documentation as well seems to be in a state of
> flux between the older 3.x docs and the new 4.x functionality.

At the moment the only way around this is to uninstall IPA master on
this server and re-run the installation.

rob

-- 
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] TLS 1.2 for PKI+SLAPD

[Rob Crittenden]

Callum Guy wrote:
> Hi All,
> 
> I'm currently looking at hardening my FreeIPA server as part of a PCI
> assessment.
> 
> I am hoping to be able to fix PKI (ports 8443) and SLAPD (LDAPS) to use
> only TLS1.2 - both currently support TLS1.0 and unfortunately that is
> non-compliant for my environment.
> 
> Also i'm very much hoping not to break my installation!
> 
> Does anyone have experience in this area?

It depends very much on what version you are running but see
https://access.redhat.com/articles/2801181 for inspiration.

rob

-- 
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] "Purge" scripts?

[Rob Crittenden]

Robert L. Harris wrote:
> 
> "apt-get remove --purge "  or "dpkg -P " should remove all
> files.  One a previous build I tried the --uninstall and got an error. 
> Right now I'm trying the PPA and 17.04 and getting a KRB error.

As I said, configuration is not erased on package removal, on purpose
(in Fedora anyway, I've never examined the debian packaging).

Without exact error messages and logs it will be very difficult to
diagnose the problems you're having.

rob

> 
> On Thu, Apr 27, 2017 at 9:06 AM Rob Crittenden <rcrit...@redhat.com
> <mailto:rcrit...@redhat.com>> wrote:
> 
> Martin Bašti wrote:
> >
> >
> > On 26.04.2017 20:07, Robert L. Harris wrote:
> >>   So twice now I've tried installing freeipa on an Ubuntu 16.04
> >> system.  Both times I've gotten an error and followed the
> instructions
> >> to "fix it" and they didn't work so I removed files ( with purge ),
> >> cleaned up everything I could find related to freeipa, sssd and kerb
> >> but trying to run it again gives either a different error or the same
> >> error with a different process output indicating it's not 100% clean.
> >>
> >>Is there a known list of paths, packages or files to make sure are
> >> un-installed or wiped out to make the system 100% clean?  Preferably
> >> for Ubuntu.
> >>
> >> Robert
> >>
> >>
> >>
> >
> > Hello, could you be more specific about the errors?
> 
> I think it is a misunderstanding. Removing the packages doesn't undo the
> configuration. I think he needs to reinstall the packages and run
> ipa-server-install --uninstall (though the ipa-upgrade post-install
> command may blow up on reinstall).
> 
> rob
> 

-- 
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] "Purge" scripts?

[Rob Crittenden]

Martin Bašti wrote:
> 
> 
> On 26.04.2017 20:07, Robert L. Harris wrote:
>>   So twice now I've tried installing freeipa on an Ubuntu 16.04
>> system.  Both times I've gotten an error and followed the instructions
>> to "fix it" and they didn't work so I removed files ( with purge ),
>> cleaned up everything I could find related to freeipa, sssd and kerb
>> but trying to run it again gives either a different error or the same
>> error with a different process output indicating it's not 100% clean.  
>>
>>Is there a known list of paths, packages or files to make sure are
>> un-installed or wiped out to make the system 100% clean?  Preferably
>> for Ubuntu.
>>
>> Robert
>>
>>
>>
> 
> Hello, could you be more specific about the errors?

I think it is a misunderstanding. Removing the packages doesn't undo the
configuration. I think he needs to reinstall the packages and run
ipa-server-install --uninstall (though the ipa-upgrade post-install
command may blow up on reinstall).

rob

-- 
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...

[Rob Crittenden]

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.

Doubtful.

cert-find and cert-show use different APIs in dogtag. cert-find uses the
newer RESTful API and cert-show uses the older XML-based API (and is
authenticated). I'm guessing that is where the issue lies.

What I'd recommend doing is noting the time, restarting the CA, and then
plow through the debug log looking for failures. It could be that the CA
is only partially up (and I'd check your CA subsystem certs as well).

rob

> 
> 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
>



>>>
>>>
>>>
>>
>>
>>
> 
> 
> 

-- 
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 PKI Questions

[Rob Crittenden]

Kendal Montgomery wrote:
> Hi all,
> 
>  
> 
> I’ve been struggling the last few days with rebuilding part of my
> FreeIPA infrastructure, which has lead me to some questions about how
> some of the IPA infrastructure works.  To give a bit of background, I
> have two IPA servers (my initially installed IPA server, and a replica)
> both of which have DNS, NTP, and CA roles.  I’m running CentOS 7.3,
> FreeIPA 4.4 currently (upgraded from original CentOS 7 installations
> which I believe was FreeIPA 4.1? initiall).  I have several remote sites
> that each have two IPA server replicas that have replication topology
> segments for domain and ca suffixes back to the two on-prem IPA
> servers.  This has been working quite well for over a year now, through
> the upgrades, etc.  Occasionally I get an issue with getting some
> conflicting records in LDAP, which I’ve cleared up by following some of
> the documentation out there.  It seems when this happens however, I end
> up getting into a situation where replication stops working, and I end
> up needing to “refresh” the installations. I have done this once so far,
> and am in the process again currently, by deleting each remote IPA
> server (ipa server-del), then re-installing each server to get a clean
> copy of the databases for everything.  Last time I had no issues doing
> this.  This time around, I’m running into some issues with the CA
> setup.  I seem to be able to run ipa-replica-install just fine without
> the --setup-ca option.  I may be running into some issues identified in
> an earlier post this week, so I’ll ask about this issue separately if I
> continue to have problems.  In working through these issues, I realized
> I don’t really know enough about how the interaction between the IPA
> clients and IPA server is working, with regard to the PKI
> infrastructure.  I have some questions on what server roles I need at
> each site and how the PKI infrastructure works within the IPA
> environment, and how the clients communicate to it:
> 

You don't need to uninstall a master in order to fix replication issues.
You can re-initialize it from a working master. I'm pretty sure that if
you re-init one you need to re-init them all though, to be safe. I cc'd
a couple of 389-ds devs to clarify.

> 
> 1)   How do the IPA clients discover servers with the CA role and
> use them?

They don't, they talk to one of the IPA masters and lets that figure it out.

An IPA master does this by looking at cn=,
cn=masters,cn=ipa,cn=etc,$SUFFIX

> 2)   Is all this interaction done through APIs on the IPA server –
> in other words, are these requests fielded by the IPA server and proxied
> somehow to known servers with the CA role?

Right.

> 3)   Do the clients need “direct” access to a server with the CA
> role to request and obtain certificates and renewals? (i.e. do I need
> each IPA server to have the CA role)?

Nope.

> 4)   Is it sufficient to just have one server with CA role at each
> site?  Or even just one at the main on-prem site?

One per site may be sufficient, you want to ensure that you have > 1 CAs
and since you have separate sites, having one at each would give you
lots of leeway in case of catastrophe.

rob

-- 
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...

[Rob Crittenden]

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?

Apache proxies requests to the CA so there could be a mismatch I
suppose. I'd ensure that the pki processes are running on the box for
starters and then dig into the CA debug log for more details.

rob
> 
> 
> 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

>>>
>>>
>>>
>>
>>
>>
> 
> 
> 

-- 
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] Default SELinux user changes on addition of replica?

[Rob Crittenden]

Steve Huston wrote:
> In the last of my testing before deployment, I had a replica server
> setup but things got out of sync somehow.  Yesterday I severed the
> link with the two servers, reimaged the "bad" one, and did some poking
> around on the "good" one while I was at it (clearing out all of the
> real user data in anticipation of making another migration run into
> it).  I remember at one point I had found the default selinux user was
> misconfigured, and I thought it was strange because that's on my
> checklist for installing a server so I know I'd done it.  Oh well,
> changed it to the proper context again and moved on.
> 
> Just this morning I made the new (previously bad) server a replica
> again, and after it finished I happened into the configuration page to
> find the default selinux user is back to unconfined_u:s0-s0:c0.c1023.
> Both servers report this the same, as I would expect, but I don't
> expect or understand why it changed again.
> 
> I don't know that I'll have time to spin up more instances and go
> through the testing to see what/when/how it changed, but I wanted to
> point it out in case someone who does have that time can run with the
> information.
> 

Seems like an update file could reset that but there isn't one that does
this that I can find.

I wonder if you fixed it on the "bad" one after replication had broken
but before you noticed it was broken, so the value was lost when the
"bad" one was dropped.

I guess the only way to know for sure would be to try to duplicate it.

rob

-- 
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 web UI: An error has occurred (IPA Error 4302: CertificateFormatError)

[Rob Crittenden]

Andrew Krause wrote:
> Sorry for the self bump but no one has any insight on this?
> 
> 
>> On Apr 17, 2017, at 11:31 AM, Andrew Krause 
>>  wrote:
>>
>> Many hosts in our web ui show a null status for “enrolled”.  When you do a 
>> search that includes any of these host objects the web UI posts errors, and 
>> if you click on one of the problem hosts the same error stops anything from 
>> loading on the host page.  
>>
>> I’ve been trying to solve this problem on my own for quite some time and 
>> have not been successful.  It’s impossible to remove the host through the 
>> web UI and using CLI commands seem to remove the entry from IPA (host is not 
>> found with ipa host-find), but it is still visible in the UI.  One thing 
>> that may be common with all of these hosts is that they were enrolled with 
>> our IPA system back while we were running version 3.0 and likely have had 
>> issues for quite some time.  Multiple updates have happened since then, and 
>> all of our hosts added within the last year are working fine.  I suspect 
>> there’s an issue with a path somewhere for a certificate database, but I’m 
>> unable to pinpoint what is going wrong.  

It should not be possible to have different views in the UI and the CLI
since they make the same backend calls. What you'd want to do, hopefully
on a semi-quiet system, is to do a host-find on the CLI and then list
all hosts in the UI and compare the logs in /var/log/httpd/error_log and
look at the LDAP queries in /var/log/dirsrv/slapd-REALM/access (this is
a buffered log so be patient).

They should be doing more or less the exact same set of queries.

Very doubtful that this has anything to do with certs. Anything on the
client would be completely separate from what is on the server.

One thing you may be seeing though is that in 3.0 clients a host
certificate was obtained for it. This was dropped with 4.0, but it
wouldn't affect any visibility on the server.

rob

-- 
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] cannot add posix group or user

[Rob Crittenden]

Cox, Jason wrote:
> 
>> Thank you. 
> Setting the id ranges manually fixed my problem.

Great, glad you're up and running again.

I forwarded the stack trace to the 389-ds developers, thanks for that.

rob

-- 
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] What's the proper format for an automember serverhostname rule?

[Rob Crittenden]

g...@greg-gilbert.com wrote:
> Rob, here's what I see in that log:
> 
> 2017-04-19T21:18:23Z DEBUG Using servers from command line, disabling
> DNS discovery
> 2017-04-19T21:18:23Z DEBUG will use provided server: ipa.services.foo
> 2017-04-19T21:18:23Z DEBUG will use discovered realm: IPA.SERVICES.FOO
> 2017-04-19T21:18:23Z DEBUG will use discovered basedn:
> dc=ipa,dc=services,dc=foo
> 2017-04-19T21:18:23Z INFO Client hostname: 10.100.15.209
> 2017-04-19T21:18:23Z DEBUG Hostname source: Provided as option
> 2017-04-19T21:18:23Z INFO Realm: IPA.SERVICES.FOO
> ...
> 2017-04-19T21:18:23Z DEBUG Starting external process
> 2017-04-19T21:18:23Z DEBUG args=/bin/hostname 10.100.15.209
> 2017-04-19T21:18:23Z DEBUG Process finished, return code=0
> 2017-04-19T21:18:23Z DEBUG stdout=
> 2017-04-19T21:18:23Z DEBUG stderr=
> 2017-04-19T21:18:23Z DEBUG Backing up system configuration file
> '/etc/hostname'
> 
> So whatever that external process is, I guess that's what's resetting
> the hostname.
> 
> For reference, here's the line that runs (on cloud-init) to set up FreeIPA:
> 
>   /usr/sbin/ipa-client-install \
>   --domain=ipa.services.FOO \
>   --server=ipa.services.FOO \
>   -U \
>   --permit \
>   --ssh-trust-dns \
>   --principal=enrollment \
>   --password="PASS" \
>   --hostname="{{ ansible_eth0.ipv4.address }}"


Right. Don't do that.

rob

> 
> 
> On 2017-04-19 16:27, Rob Crittenden wrote:
> 
>> g...@greg-gilbert.com <mailto:g...@greg-gilbert.com> wrote:
>>> When the instances register themselves with FreeIPA, their hostnames get
>>> changed to match their IP; that's a FreeIPA rule, I believe. So in this
>>> case, the hostname is 10.100.*.
>>>
>>> ubuntu@10:~$ hostname
>>> 10.100.15.130
>>
>> There is something very wrong. ipa-client should be setting a FQDN, not
>> an IP address. /var/log/ipaclient-install.log may hold some clues.
>>
>> rob
>>
>>>
>>> On 2017-04-19 14:53, Jason B. Nance wrote:
>>>
>>>> Hi Greg,
>>>>
>>>> I'm trying to set up a rule based on server hostname. So for
>>>> example, 10.100.* would be put into the 'developers' hostgroup. I
>>>> can't figure out the proper format of the inclusive regex. I've
>>>> tried:
>>>>
>>>> I believe that your regex needs to match the host name, not the IP
>>>> address.  Unless your host name is 10.100. I don't think
>>>> that will match.  The regex for "anything" is ".*".  I think that the
>>>> pcre syntax is what is used.
>>>> Regards,
>>>>  
>>>> j
>>>>  
>>>
>>>
>>>
>>>
> 

-- 
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] What's the proper format for an automember serverhostname rule?

[Rob Crittenden]

g...@greg-gilbert.com wrote:
> When the instances register themselves with FreeIPA, their hostnames get
> changed to match their IP; that's a FreeIPA rule, I believe. So in this
> case, the hostname is 10.100.*.
> 
> ubuntu@10:~$ hostname
> 10.100.15.130

There is something very wrong. ipa-client should be setting a FQDN, not
an IP address. /var/log/ipaclient-install.log may hold some clues.

rob

> 
> On 2017-04-19 14:53, Jason B. Nance wrote:
> 
>> Hi Greg,
>>
>> I'm trying to set up a rule based on server hostname. So for
>> example, 10.100.* would be put into the 'developers' hostgroup. I
>> can't figure out the proper format of the inclusive regex. I've tried:
>>
>> I believe that your regex needs to match the host name, not the IP
>> address.  Unless your host name is 10.100. I don't think
>> that will match.  The regex for "anything" is ".*".  I think that the
>> pcre syntax is what is used.
>> Regards,
>>  
>> j
>>  
> 
> 
> 
> 

-- 
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] cannot add posix group or user

[Rob Crittenden]

Cox, Jason wrote:
> Hi all,
> 
>  
> 
> I had to reinstall my IPA setup, so I’m using 4.4 and am learning the
> newer domain levels and topology features.
> 
> I’ve installed 3 servers.
> 
> I promoted one of the replicas to master and demoted the original master
> to replica according to the documentation.

According to what documentation?

Note that they are all masters, some may just run different services and
only one has a few duties (like CRL generation).

> I ran into an issue with the original master no longer replicating, so I
> performed an ipa-server-install –uninstall and removed the host/server
> from IPA.

This is the where the problem started.

> 
> I re-setup the replica using ipa-client-install and then
> ipa-replica-install, and had no errors reported in the output.
> 
> I then went into Web UI and setup replication agreements using the
> topology graph page between the new replica and the previous replica
> (the master/new replica agreements being setup by the replica install
> script).
> 
>  
> 
> I then attempted to add a posix group account and got an operational
> error message. This caused ldap to crash on the server I was interfacing
> with.

If you are getting a core it would be very enlightening to get a stack
trace from that (you'll need to install the debuginfo package to get any
really useful data out of it).

> 
> I performed an ‘ipactl restart’ on the affected server and attempted
> again with the same issue.
> 
> I tried adding a non-posix group and it was successful.
> 
>  
> 
> I found the dirsrv logs and see the error ‘dna-plugin - dna_pre_op: no
> more values available!!’ which lead me to
> https://www.redhat.com/archives/freeipa-users/2014-February/msg00247.html
> 
>  
> 
> Performing the ldapserch I see:
> 
>   dnaMaxValue is 1100
> 
>   dnaNextValue is 1101
> 
>   dnaThreshold is 500

Right. A master only gets a range when it needs one. In this case it
needed one after the master holding the entire range went away.

> I also did ‘ipa idrange-find’, which shows:
> 
>  
> 
> ---
> 
> 1 range matched
> 
> ---
> 
>   Range name: MYDOMAIN.COM_id_range
> 
>   First Posix ID of the range: 194600
> 
>   Number of IDs in the range: 20
> 
>   Range type: local domain range
> 
> 
> 
> Number of entries returned 1
> 
> 
> 
>  
> 
>  
> 
> So now my question is what do I need to change to fix the issue?
> 
> I can do the ldapmodify to adjust the dnaMaxValue, but I don’t know what
> I should be adjusting the idrange to?
> 
> I’d like to keep the idrange the same and just adjust the dnaMaxValue,
> so would I need to change dnaMaxValue to 20?

See https://blog-rcritten.rhcloud.com/?p=50

rob

-- 
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] renewing cert and migrating free-ipa 3.1

[Rob Crittenden]

Umarzuki Mochlis wrote:
> Now users complaining that passwords that have been reset cannot be
> used to log in.

Passwords are completely unrelated to expired certificates.

Wow, this is really quite an old install.

The error message about communicating with CMS suggests that the CA
isn't really up. The dogtag debug log may contain more details on that.

What is the output when you use ipactl to restart the services? I have
the feeling it is catching an error that your manual restart is not.

I'd also not set the date back so far. It won't hurt but it will be the
starting date for new certificates so you'd be cheating yourself out of
8 or so months.

I'd also look at the RA agent cert to be sure it is currently correct:

$ ldapsearch -x -h localhost -p 7389 -D 'cn=directory manager' -W -b
uid=ipara,ou=People,o=ipaca description

$ certutil -L -d /etc/httpd/alias -n ipaCert | grep Serial

The description field from the ldapsearch has the format:

2;;;

The serial numbers should match. Don't do anything if they don't, just
report back the result.

rob

> I also tried resubmit getcert but 2 resubmit failed
> 
> [root@ipa ~]# getcert list
> Number of certificates and requests being tracked: 7.
> Request ID '20130112120226':
> status: MONITORING
> stuck: no
> key pair storage:
> type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='auditSigningCert
> cert-pki-ca',token='NSS Certificate DB',pin='932018712055'
> certificate:
> type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='auditSigningCert
> cert-pki-ca',token='NSS Certificate DB'
> CA: dogtag-ipa-renew-agent
> issuer: CN=Certificate Authority,O=DOA.GOV.MY
> subject: CN=CA Audit,O=DOA.GOV.MY
> expires: 2016-11-24 16:19:25 UTC
> pre-save command:
> post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert
> "auditSigningCert cert-pki-ca"
> track: yes
> auto-renew: yes
> Request ID '20130112120227':
> status: MONITORING
> stuck: no
> key pair storage:
> type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='ocspSigningCert
> cert-pki-ca',token='NSS Certificate DB',pin='932018712055'
> certificate:
> type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='ocspSigningCert
> cert-pki-ca',token='NSS Certificate DB'
> CA: dogtag-ipa-renew-agent
> issuer: CN=Certificate Authority,O=DOA.GOV.MY
> subject: CN=OCSP Subsystem,O=DOA.GOV.MY
> expires: 2016-11-24 16:18:25 UTC
> eku: id-kp-OCSPSigning
> pre-save command:
> post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert
> "ocspSigningCert cert-pki-ca"
> track: yes
> auto-renew: yes
> Request ID '20130112120228':
> status: MONITORING
> stuck: no
> key pair storage:
> type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='subsystemCert
> cert-pki-ca',token='NSS Certificate DB',pin='932018712055'
> certificate:
> type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='subsystemCert
> cert-pki-ca',token='NSS Certificate DB'
> CA: dogtag-ipa-renew-agent
> issuer: CN=Certificate Authority,O=DOA.GOV.MY
> subject: CN=CA Subsystem,O=DOA.GOV.MY
> expires: 2016-11-24 16:18:25 UTC
> eku: id-kp-serverAuth,id-kp-clientAuth
> pre-save command:
> post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert
> "subsystemCert cert-pki-ca"
> track: yes
> auto-renew: yes
> Request ID '20130112120229':
> status: MONITORING
> 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=DOA.GOV.MY
> subject: CN=IPA RA,O=DOA.GOV.MY
> expires: 2016-11-24 16:18:25 UTC
> 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 '20130112120230':
> status: MONITORING
> stuck: no
> key pair storage:
> type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='Server-Cert
> cert-pki-ca',token='NSS Certificate DB',pin='932018712055'
> certificate:
> type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='Server-Cert
> cert-pki-ca',token='NSS Certificate DB'
> CA: dogtag-ipa-renew-agent
> issuer: CN=Certificate Authority,O=DOA.GOV.MY
> subject: CN=ipa.domain.com.my,O=DOA.GOV.MY
> expires: 2016-11-24 16:18:25 UTC
> eku: id-kp-serverAuth,id-kp-clientAuth
> pre-save command:
> post-save command: /usr/lib64/ipa/certmonger/restart_pkicad
> "Server-Cert cert-pki-ca"
> track: yes
> auto-renew: yes
> Request ID '20130112120232':
> status: CA_UNREACHABLE
> ca-error: Server failed request, will retry: 4301 (RPC failed at
> server.  Certificate operation cannot be completed: Unable to
> communicate with CMS 

Re: [Freeipa-users] 'NoneType' object is not iterable when removing broken ipa-server replica

[Rob Crittenden]

Jake wrote:
> Help!
> I'm having issues removing a bad replica.
> 
> Everytime I run:
> 
> ipa-replica-manage del ipa01.example.com
> or
> ipa-replica-manage del --force ipa01.example.com
> 
> I get an error: 'NoneType' object is not iterable
> 
> if I try to remove it from the web interface:
> 
> 
> IPA Error 903: InternalError
> 
> an internal error has occurred

I wonder if a traceback is logged in /var/log/httpd/error_log

> They're removed from hosts, but I cannot get them our of the existing
> topology

Not sure what you mean here.

> 
> Is there a "purge this host" button that removes it, ignoring errors if
> it's already missing.

--force ignore some errors but not unknown errors like this.

What version of IPA is this?

rob

-- 
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] strange error when running "ipa help topics"

[Rob Crittenden]

Chris Dagdigian wrote:
> 
> Never seen this one before,  any hints?
> 
> testidm]# ipa help topics
> ipa: ERROR: error marshalling data for XML-RPC transport: message: need
> a ; got 'No valid Negotiate header in server response'
> (a )

What version of client and what version of server?

Newer clients fetch the schema from the server in order to build the
parameters. Looks like that retrieval is failing for some reason.

You can add a few -v's to the ipa command to provide more details on
what is being sent and received, e.g. ipa -vvv help topics

rob

-- 
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] Centos7/IPA4.2 : disable/enable hosts

[Rob Crittenden]

Johan Vermeulen wrote:
> Rob,
> 
> thanks for helping me out.
> I support some 80 laptop users at the moment, all running Centos7.
> The users are now in ldap, the laptops ( hosts) are not. I'm testing the
> ability to add the laptops as hosts.
> 
> Under "identity - hosts", when selecting a host, I go to "actions". The
> only way I see to disable ( block) a host, what I would do when
> a laptop is stolen for instance, is unprovision.
> I then tried to re-provision it, I see no "provision" option. I tried to
> "rebuild auto membership" and " new certificate" but that doesn't seem
> to work.
> I hope I'm making sense.

In the case of a lost or stolen laptop then disabling the host seems
like a good mechanism. It will revoke and certificates issued for the
host and invalidate its keytab.

Provisioning happens when ipa-client-install is run on the host [1].
There is no facility for remote provisioning.

rob

[1] technically a host is provisioned when it has a keytab but this
doesn't configure that host to actually use it and you potentially need
to safely transfer this keytab to the host.

-- 
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] Centos7/IPA4.2 : disable/enable hosts

[Rob Crittenden]

Johan Vermeulen wrote:
> Hello All,
> 
> just getting started with FreeIPA and one of the first features I'm
> trying is adding hosts, something I can't do in our current
> ldap-setup. So I'm looking forward to being able to do this.
> But after adding a host, the only way I see to disable it is unprovision
> it. And after doing that, I can' t find a way to re-provision the host.
> 
> Can anybody point me in the right direction regarding this?

I'm not sure I follow what you're doing and don't want to guess and send
you on a wild goose chase :-)

Can you elaborate on your workflow and the output you're seeing when you
try to re-provision?

rob

-- 
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 Ldap only as Client on different IPA server

[Rob Crittenden]

Matt . wrote:
> The issue you get here is that the IPA client is not enrolled anymore
> when you did an uninstall of the client before the IPA install on that
> "previous" client which needs to be client again after the IPA install
> on it.
> 
> This sounds messy but could be ideal for some situations of useraccess
> on systems.

Installing an IPA master configures it as a client for that master,
there is no way around it.

You can't (or shouldn't) mix and match discrete IPA installations.
Eventually there will be intra-IPA trust which will do you what I think
you are looking for.

rob

> 
> 2017-04-07 23:24 GMT+02:00 Rob Crittenden <rcrit...@redhat.com>:
>> Matt . wrote:
>>> Nope, I provision my servers and they are added to my FreeIPA
>>> environment which auths my systeadmins. But on a server I provisioned
>>> I need to install FreeIPA as well, but without dns and ca, so it's
>>> doing ldap only actually.
>>>
>>> When I want to install FreeIPA server on this IPA client it tells me
>>> (which is logical):
>>>
>>> ipa.ipapython.install.cli.install_tool(Server): ERRORIPA client is
>>> already configured on this system.
>>> Please uninstall it before configuring the IPA server, using
>>> 'ipa-client-install --uninstall'
>>>
>>> So what I want to do is install FreeIPA server on it but using local
>>> system accounts to be auth against the former IPA server the client
>>> was assigned to.
>>>
>>> So:
>>>
>>> IPA01 get's a host which is LDAP01 but LDAP01 needs to be installed
>>> with FreeIPA (no dns and CA) as well but I want to have local
>>> sysaccounts that login to cli and such auth against IPA01 after it's
>>> installed with FreeIPA and the clientconfig for sssd is not there
>>> anymore because of the 'ipa-client-install --uninstall'
>>
>> Still very confusing. LDAP has nothing to do with this. IPA is always at
>> least LDAP + Kerberos + Apache + a few other minor services. So it's
>> better to just say no DNS and no CA, though that isn't really relevant
>> since those are always optional.
>>
>> It sounds like what you want to do is, on the same box, install IPA
>> server and configure the local machine to point to a DIFFERENT IPA
>> server for user/group lookups?
>>
>> You might be able to do it via sssd but it would be an unsupportable
>> nightmare.
>>
>> rob
>>
>>>
>>> 2017-04-07 23:11 GMT+02:00 Rob Crittenden <rcrit...@redhat.com>:
>>>> Matt . wrote:
>>>>> When I have a full ipa setup and I want to add a host to it that is
>>>>> installed or needs to be installed as IPA LDAP server only, is that
>>>>> possible ?
>>>>
>>>> If you're asking if only 389-ds can be configured on an IPA server, no,
>>>> not using any IPA tools in any case.
>>>>
>>>>> Of course the ipa-server-install complains that the agent is already
>>>>> configured on the host but there might be a way ? Or just copy the
>>>>> config back faster the IPA LDAP only server is installed ?
>>>>
>>>> I don't understand. Seeing the error message and commands might help.
>>>>
>>>> rob
>>>>
>>

-- 
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 Ldap only as Client on different IPA server

[Rob Crittenden]

Matt . wrote:
> Nope, I provision my servers and they are added to my FreeIPA
> environment which auths my systeadmins. But on a server I provisioned
> I need to install FreeIPA as well, but without dns and ca, so it's
> doing ldap only actually.
> 
> When I want to install FreeIPA server on this IPA client it tells me
> (which is logical):
> 
> ipa.ipapython.install.cli.install_tool(Server): ERRORIPA client is
> already configured on this system.
> Please uninstall it before configuring the IPA server, using
> 'ipa-client-install --uninstall'
> 
> So what I want to do is install FreeIPA server on it but using local
> system accounts to be auth against the former IPA server the client
> was assigned to.
> 
> So:
> 
> IPA01 get's a host which is LDAP01 but LDAP01 needs to be installed
> with FreeIPA (no dns and CA) as well but I want to have local
> sysaccounts that login to cli and such auth against IPA01 after it's
> installed with FreeIPA and the clientconfig for sssd is not there
> anymore because of the 'ipa-client-install --uninstall'

Still very confusing. LDAP has nothing to do with this. IPA is always at
least LDAP + Kerberos + Apache + a few other minor services. So it's
better to just say no DNS and no CA, though that isn't really relevant
since those are always optional.

It sounds like what you want to do is, on the same box, install IPA
server and configure the local machine to point to a DIFFERENT IPA
server for user/group lookups?

You might be able to do it via sssd but it would be an unsupportable
nightmare.

rob

> 
> 2017-04-07 23:11 GMT+02:00 Rob Crittenden <rcrit...@redhat.com>:
>> Matt . wrote:
>>> When I have a full ipa setup and I want to add a host to it that is
>>> installed or needs to be installed as IPA LDAP server only, is that
>>> possible ?
>>
>> If you're asking if only 389-ds can be configured on an IPA server, no,
>> not using any IPA tools in any case.
>>
>>> Of course the ipa-server-install complains that the agent is already
>>> configured on the host but there might be a way ? Or just copy the
>>> config back faster the IPA LDAP only server is installed ?
>>
>> I don't understand. Seeing the error message and commands might help.
>>
>> rob
>>

-- 
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 Ldap only as Client on different IPA server

[Rob Crittenden]

Matt . wrote:
> When I have a full ipa setup and I want to add a host to it that is
> installed or needs to be installed as IPA LDAP server only, is that
> possible ?

If you're asking if only 389-ds can be configured on an IPA server, no,
not using any IPA tools in any case.

> Of course the ipa-server-install complains that the agent is already
> configured on the host but there might be a way ? Or just copy the
> config back faster the IPA LDAP only server is installed ?

I don't understand. Seeing the error message and commands might help.

rob

-- 
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] user keytab retrieval

[Rob Crittenden]

Stijn De Weirdt wrote:
> hi rob,
> 
>>> i'm a bit puzzled by the following: i want to retrieve a user keytab
>>> using ipa-getkeytab -r (since the keytab for the same user was already
>>> retrieved on another host).
>>>
>>> when doing so, i get
>>>
>>> Failed to parse result: Insufficient access rights
>>>
>>> however, i can get the keytab without the -r option.
>>>
>>> anyone care to explain what access rights are required (or why this
>>> error occurs)?
>>
>> Being able to retrieve an existing key means being able to read it which
>> isn't granted by default.
> ok, but why is a "regular" ipa-getkeytab no problem?

Because writing keys is granted by default.

>>
>> It depends on how you want to grant this access: to this one user, to
>> all users, to groups, etc.
> i only need to get the user keytab on a few machines; i could probably
> scp it from one host to the other. but i assumed that ipa-getkeytab -r
> would do the same.
> 
>>
>> The attribute you want is ipaProtectedOperation;read_keys but use it
>> very carefully because you are granting read access to keys.
> ok, i'll try to read a bit more about it first.

You may end up having to hand-write an ACI to handle this. Given you
only want to allow it for a few entries you can add the ACI directly
under the entries you want to allow reading to limit exposure.

rob

-- 
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] user keytab retrieval

[Rob Crittenden]

Stijn De Weirdt wrote:
> hi all,
> 
> (this is IPA 4.4.0-14.el7.centos.4)
> 
> i'm a bit puzzled by the following: i want to retrieve a user keytab
> using ipa-getkeytab -r (since the keytab for the same user was already
> retrieved on another host).
> 
> when doing so, i get
> 
> Failed to parse result: Insufficient access rights
> 
> however, i can get the keytab without the -r option.
> 
> anyone care to explain what access rights are required (or why this
> error occurs)?

Being able to retrieve an existing key means being able to read it which
isn't granted by default.

It depends on how you want to grant this access: to this one user, to
all users, to groups, etc.

The attribute you want is ipaProtectedOperation;read_keys but use it
very carefully because you are granting read access to keys.

rob

-- 
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-getkeytab client equivalent for Unix

[Rob Crittenden]

Iulian Roman wrote:
> Hello,
> 
> Can anybody explain briefly what ipa-getkeytab runs under the hood in
> order to use similar logic for unix clients (will help in automating 
> the registration to IPA server)  ? 
> 
> Thank You !

Honestly your best bet would be to pull the freeipa source and look at
client/ipa-getkeytab.c.

In short it fetches keytabs over LDAP using an extended operation.

rob

-- 
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] MAKE Freeipa replica not work now

[Rob Crittenden]

barry...@gmail.com wrote:
> Hi all:
> 
> 9444 port can be telnet ...Any idea ? the log show below as I don't have
> more idea... If I plan to
> migrate to same version of server what I have to copy ? as I saw
> step of migration also similar to replica so now stuck on the steps.
> Any Manual copy steps ? as I copy and paste the LDAP of ABC.com
> and slapd_PKI ..It cannot start up ...can I just move slapd_ABC.com
> 's ldif other ignored ? many thks

I'm not quite sure I follow. It seems there is a bit of history we're
missing here. What is it you're trying to do? It sounds like more than
just stand up another master.

> Preparing replica for central.ABC.com  from
> central.wisers.com 
> Creating SSL certificate for the Directory Server
> preparation of replica failed: cannot connect to
> 'https://central.ABC.com:9444/ca/ee/ca/profileSubmitSSLClient':
> (PR_END_OF_FILE_ERROR) Encountered end of file.
> cannot connect to
> 'https://central.ABC.com:9444/ca/ee/ca/profileSubmitSSLClient':
> (PR_END_OF_FILE_ERROR) Encountered end of file.
>   File "/usr/sbin/ipa-replica-prepare", line 490, in 
> main()
> 
>   File "/usr/sbin/ipa-replica-prepare", line 361, in main
> export_certdb(api.env.realm, ds_dir, dir, passwd_fname, "dscert",
> replica_fqdn, subject_base)
> 
>   File "/usr/sbin/ipa-replica-prepare", line 150, in export_certdb
> raise e

What version of IPA?

You'll want to check the dogtag logs for more details, the location
depends on the version.

rob

-- 
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] Migrate IPA cluster F21 -> C7

[Rob Crittenden]

Bret Wortman wrote:
> Never mind. Lost my mind.
> 
> ipa-replica-install followed by ipa-ca-install appears to be the ticket.

Or you can do it in one step by passing --setup-ca to ipa-replica-install

rob

> 
> 
> Bret
> 
> 
> On 03/29/2017 06:22 AM, Bret Wortman wrote:
>>
>> I've tried googling but keep coming up with beer recipes.
>>
>> How do you suggest adding the replica CA? I'm piecing together the
>> options I want on my ipa-server-install command and am trying to
>> understand the CA-related options.
>>
>> Thanks!
>>
>>
>> Bret
>>
>>
>>
>> On 03/28/2017 08:45 AM, Bret Wortman wrote:
>>> I'm studying the best way to migrate out IPA servers (there are two)
>>> from F21 to C7. I _think_ the sequence of steps I need to perform is:
>>>
>>> 1. Build new C7 IPA server (ipa-c) and enable replication to it.
>>> 2. Migrate CA functions from our existing CA server (ipa-a) to
>>> this new one (ipa-c).
>>> 3. Upgrade ipa-b to C7 and enable replication to it.
>>> 4. Either upgrade ipa-a and have a third ipa server or discard
>>> the vm in favor of the two now in service.
>>>
>>> Am I missing anything? Making this harder than it needs to be?
>>>
>>> Our F21 servers are using IPA 4.1.4-1 (and pki-ca 10.2.1-3) so I'm
>>> not if replication across versions is supported between these and IPA
>>> 4.4.0 (pki-ca 10.3.3).
>>>
>>>
>>> -- 
>>> *Bret Wortman*
>>> Damascus Products
>>> ph/fax: 1-855-644-2783
>>> Wrap Buddies InDemand  at
>>> http://bwortman.us/2ieQN4t
>>
> 
> 
> 

-- 
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] Migrate IPA cluster F21 -> C7

[Rob Crittenden]

Bret Wortman wrote:
> I'm studying the best way to migrate out IPA servers (there are two)
> from F21 to C7. I _think_ the sequence of steps I need to perform is:
> 
> 1. Build new C7 IPA server (ipa-c) and enable replication to it.
> 2. Migrate CA functions from our existing CA server (ipa-a) to this
> new one (ipa-c).
> 3. Upgrade ipa-b to C7 and enable replication to it.
> 4. Either upgrade ipa-a and have a third ipa server or discard the
> vm in favor of the two now in service.
> 
> Am I missing anything? Making this harder than it needs to be?
> 
> Our F21 servers are using IPA 4.1.4-1 (and pki-ca 10.2.1-3) so I'm not
> if replication across versions is supported between these and IPA 4.4.0
> (pki-ca 10.3.3).

This looks fine. I'd ensure there are at least 2 IPA Masters installed
with a CA in order to avoid a single point of failure.

rob

-- 
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] Automount location design

[Rob Crittenden]

Z D wrote:
> Hi there,
> 
> We've been looking to add indirect maps for users home directories, and
> did the next.
> 
> 1. There is the automount location (named "global") with one map
> "auto_home", it has keys (they are username) and mount info is
> :/path
> 
> 2. The idea is that this is "global location"
> 
> 3. Another location (named "userdirs") has auto.master map with key =
> "/home" and mount info is like
> "ldap:automountmapname=auto_home,cn=global,cn=automount,dc=comp,dc=com"
> 
> 4. It was added with command:
> 
>  ipa automountkey-add userdirs auto.master --key=/home
> --info=ldap:automountmapname=auto_home,cn=global,cn=automount,dc=comp,dc=com
> 
> 5. All work as expected, the issue is that below command shows error.
> 
> ipa automountlocation-tofiles userdirs
> ipa: ERROR:
> ldap:automountmapname=auto_home,cn=global,cn=automount,dc=comp,dc=com:
> automount map not found
> 
> Is there any concern with such design?

Arguably it's a deficiency in automountlocation-tofiles. I was having a
hard time wrapping my head around things when I wrote the automount
support oh-so-long-ago so I hacked that command up to try to see what
was being created in a file-like setting. It is, to say the least, very
simplistic code.

It doesn't parse the automountinformation attribute, it assumes it is
pointing to a key entry. It doesn't understand the ldap: prefix.

I don't believe this prefix is required but it looks like you're trying
to share the same map between two locations which we never intended.

rob

So if this

-- 
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] Directory Manager password is correct but IPA-replica-prepare command fails with Invalid Credentials

[Rob Crittenden]

Shiela Spaleta wrote:
> I can successfully bind as the Directory Manager, but when I use the
> same password to create a replica prep file I get an "Invalid
> Credentials" error.  How is this possible?
> 
> I'm running FreeIPA v3.0 on Centos 6 and created replica's successfully
> in the past.
> 
> I tested the Directory Manager password by using it change the admin
> user's password:
> 
> ldappasswd -D 'cn=directory manager' -W -S
> uid=admin,cn=users,cn=accounts,dc=domain,dc=com
> 
> and that was successful (tested by getting a ticket as admin user with
> new pwd).
> 
> But when I try to create a replica file:
> 
> # ipa-replica-prepare ipa2.shiela.com 
>
> 
> Preparing replica for ipa2.shiela.com
>  from ipa1.shiela.com 
> preparation of replica failed: Insufficient access:  Invalid credentials
> Insufficient access:  Invalid credentials
>   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 712, in handle_errors
> raise errors.ACIError(info="%s %s" % (info, desc))
> 
> If anyone can shed light on this I would be grateful.  I've checked
> /var/log/dirsrv/PKI-IPA but it has not been any more helpful.
> 

admin != Directory Manager.

Try running kdestroy, then ipa-replica-prepare. You'll be prompted for
the DM password, that should work.

rob

-- 
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] Use SQLite format NSS database?

[Rob Crittenden]

Ian Pilcher wrote:
> On 03/20/2017 11:02 AM, Rob Crittenden wrote:
>> I think his concern may be around warnings that the NSS BDB databases
>> should only be updated when quiet. In the case of mod_nss it explicitly
>> opens the database read-only so I think you'd be safe updating the
>> certificate.
> 
> You are correct about my concern.  I should have noticed that mod_nss
> is opening the database read-only, based on the file permissions if
> nothing else.
> 
> Based on this, I should be able to do something with symlinks to make a
> copy of the database, do my updates, rename the symlink to make the
> updated database "live", and SIGHUP (or restart if necessary) Apache.

Um, this _might_ work. Each httpd worker will have an fd open to the NSS
database files so you'd want to do this rather carefully.

In order for NSS to see a newly added certificate it will need to reopen
the database. I'm fairly certain a SIGHUP will cause all the children to
be respawned so except for those actually serving a request at the time
the new certs should be available.

rob

-- 
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] Use SQLite format NSS database?

[Rob Crittenden]

Martin Basti wrote:
> 
> 
> On 20.03.2017 16:12, Ian Pilcher wrote:
>> On 03/20/2017 04:00 AM, David Kupka wrote:
>>> Generally I would not recommend touching this on production system.
>>> Why do you want to change the database format?
>>
>> My FreeIPA server also acts as a reverse proxy/TLS endpoint for my
>> home sprinkler system (https://opensprinkler.com/), allowing me to
>> securely connect to the sprinkler controller from my cell phone when
>> I'm out in the yard (out of WiFi range).
>>
>> Since free 1-year TLS certificates seem to be a thing of the past, I'm
>> working on automating the retrieval of 90-day certificates from Let's
>> Encrypt.
>>
>> My current update script has to stop Apache before updating the
>> certificate in the NSS database.  It's hardly the end of the world, but
>> it would have been nice to be able to load the new certificate into the
>> database and just send a SIGHUP to the daemon.
>>
> 
> Might this help for Lets encrypt ?
> https://github.com/freeipa/freeipa-letsencrypt

I think his concern may be around warnings that the NSS BDB databases
should only be updated when quiet. In the case of mod_nss it explicitly
opens the database read-only so I think you'd be safe updating the
certificate.

A SIGHUP may indeed be sufficient to load the new cert, just haven't had
a chance to test it this morning.

rob

-- 
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] any idea this error ? relate to memory?

[Rob Crittenden]

Alexander Bokovoy wrote:
> On ke, 15 maalis 2017, barry...@gmail.com wrote:
>> 8443 port already firewall open but still fail..1G memory only in web
>> hosting..free 600 M still
>>
>> 2017-03-15T01:36:47Z DEBUG The ipa-server-install command failed,
>> exception: NetworkError: cannot connect to '
>> https://centralaws.ABC.com:8443/ca/rest/account/login': Could not connect
>> to centralaws.ABC.com using any address: (PR_ADDRESS_NOT_SUPPORTED_ERROR)
>> Network address type not supported.
>> 2017-03-15T01:36:47Z ERROR cannot connect to '
>> https://aws.ABC.com:8443/ca/rest/account/login': Could not connect to
>> centralaws.ABC.com using any address: (PR_ADDRESS_NOT_SUPPORTED_ERROR)
>> Network address type not supported.
>> 2017-03-15T01:36:47Z ERROR The ipa-server-install command failed. See
>> /var/log/ipaserver-install.log for more information
> PR_ADDRESS_NOT_SUPPORTED_ERROR means your kernel does not have support
> for IPv6, it seems.
> 

I think these are basically just standard connection issues. The NSPR
error is a bit misleading, it just means it tried IPv4 and failed, then
IPv6 and failed and then ran out of network types to try so it gave up.

But in my experience at least 1.5GB of RAM are required for an IPA
install with a CA. This is the minimum size I used when developing IPA
on Fedora.

rob

-- 
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] Foreman => Insufficient 'add' privilege to the 'userPassword' attribute

[Rob Crittenden]

Matt . wrote:
> Hi Rob,
> 
> Thanks for the update, the same error happens when I add a new host,
> so I'm lost, the same for the Foreman devs.
> 
> What can I check/test further ?

See what 389-ds is logging in its access log.

You may need to enable ACI summary debugging. See the 389-ds FAQ for
instructions on how.

I find it curious that there are 2 similarly named foreman users in the
role.

rob

> 
> Thanks,
> 
> Matt
> 
> 2017-03-10 21:20 GMT+01:00 Rob Crittenden <rcrit...@redhat.com>:
>> Matt . wrote:
>>> Hi Rob,
>>>
>>> Thanks, but what do you mean here ? The Foreman has a script which
>>> should be OK for it:
>>>
>>> https://github.com/theforeman/smart-proxy/blob/develop/sbin/foreman-prepare-realm
>>>
>>> Can you check this maybe ?
>>
>> Like I said, it's wrong.
>>
>> add grants the ability to add new entries, not updating existing ones.
>>
>> The right needs to be "write".
>>
>> rob
>>
>>>
>>> Thanks,
>>>
>>> Matt
>>>
>>> 2017-03-10 17:21 GMT+01:00 Rob Crittenden <rcrit...@redhat.com>:
>>>> Matt . wrote:
>>>>> I'm trying to add a host using Foreman to the FreeIPA realm but this
>>>>> doesn't work, all things seem to be fine and some other tests from
>>>>> people are working:
>>>>>
>>>>> The issue is reported here: http://projects.theforeman.org/issues/18850
>>>>>
>>>>>
>>>>> My settings are like this:
>>>>>
>>>>>
>>>>> [root@ipa-01 ~]# ipa role-find
>>>>> ---
>>>>> 6 roles matched
>>>>> ---
>>>>>   Role name: helpdesk
>>>>>   Description: Helpdesk
>>>>>
>>>>>   Role name: IT Security Specialist
>>>>>   Description: IT Security Specialist
>>>>>
>>>>>   Role name: IT Specialist
>>>>>   Description: IT Specialist
>>>>>
>>>>>   Role name: Security Architect
>>>>>   Description: Security Architect
>>>>>
>>>>>   Role name: Smart Proxy Host Manager
>>>>>   Description: Smart Proxy management
>>>>>
>>>>>   Role name: User Administrator
>>>>>   Description: Responsible for creating Users and Groups
>>>>> 
>>>>> Number of entries returned 6
>>>>> 
>>>>> [root@ipa-01 ~]# ipa role-show "Smart Proxy Host Manager"
>>>>>   Role name: Smart Proxy Host Manager
>>>>>   Description: Smart Proxy management
>>>>>   Member users: foreman-proxy, foreman-realm-proxy
>>>>>   Privileges: Smart Proxy Host Management
>>>>> [root@ipa-01 ~]# ipa privilege-show "Smart Proxy Host Management"
>>>>>   Privilege name: Smart Proxy Host Management
>>>>>   Description: Smart Proxy Host Management
>>>>>   Permissions: Retrieve Certificates from the CA, System: Add DNS
>>>>> Entries, System: Read DNS Entries, System: Remove DNS Entries, System:
>>>>> Update DNS
>>>>>Entries, System: Manage Host Certificates, System:
>>>>> Manage Host Enrollment Password, System: Manage Host Keytab, System:
>>>>> Modify Hosts,
>>>>>System: Remove Hosts, System: Manage Service Keytab,
>>>>> System: Modify Services, Add Host Enrollment Password
>>>>>   Granting privilege to roles: Smart Proxy Host Manager
>>>>> [root@ipa-01 ~]#
>>>>> [root@ipa-01 ~]# ipa permission-find "Add Host"
>>>>> -
>>>>> 3 permissions matched
>>>>> -
>>>>>   Permission name: Add Host Enrollment Password
>>>>>   Granted rights: add
>>>>>   Effective attributes: userpassword
>>>>>   Bind rule type: permission
>>>>>   Subtree: cn=computers,cn=accounts,dc=office,dc=ipa,dc=domain,dc=tld
>>>>>   Type: host
>>>>>   Permission flags: V2, SYSTEM
>>>>>
>>>>>   Permission name: System: Add Hostgroups
>>>>>   Granted rights: add
>>>>>   Bind rule type: permission
>>>>>   Subtree: cn=hostgroups,cn=accounts,dc=office,dc=ipa,dc=domain,dc=tld
>>>>>   Type: hostgroup
>>>>>   Permission flags: V2, MANAGED, SYSTEM
>>>>>
>>>>>   Permission name: System: Add Hosts
>>>>>   Granted rights: add
>>>>>   Bind rule type: permission
>>>>>   Subtree: cn=computers,cn=accounts,dc=office,dc=ipa,dc=domain,dc=tld
>>>>>   Type: host
>>>>>   Permission flags: V2, MANAGED, SYSTEM
>>>>> 
>>>>> Number of entries returned 3
>>>>> 
>>>>>
>>>>>
>>>>> Can anyone help me out as I'm unsure where this goes wrong.
>>>>>
>>>>
>>>> For 'Add Host Enrollment Password' the granted rights should be write
>>>> not add.
>>>>
>>>> add is for adding entries, not writing attributes.
>>>>
>>>> rob
>>>
>>
> 

-- 
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] Foreman => Insufficient 'add' privilege to the 'userPassword' attribute

[Rob Crittenden]

Matt . wrote:
> Hi Rob,
> 
> Thanks, but what do you mean here ? The Foreman has a script which
> should be OK for it:
> 
> https://github.com/theforeman/smart-proxy/blob/develop/sbin/foreman-prepare-realm
> 
> Can you check this maybe ?

Like I said, it's wrong.

add grants the ability to add new entries, not updating existing ones.

The right needs to be "write".

rob

> 
> Thanks,
> 
> Matt
> 
> 2017-03-10 17:21 GMT+01:00 Rob Crittenden <rcrit...@redhat.com>:
>> Matt . wrote:
>>> I'm trying to add a host using Foreman to the FreeIPA realm but this
>>> doesn't work, all things seem to be fine and some other tests from
>>> people are working:
>>>
>>> The issue is reported here: http://projects.theforeman.org/issues/18850
>>>
>>>
>>> My settings are like this:
>>>
>>>
>>> [root@ipa-01 ~]# ipa role-find
>>> ---
>>> 6 roles matched
>>> ---
>>>   Role name: helpdesk
>>>   Description: Helpdesk
>>>
>>>   Role name: IT Security Specialist
>>>   Description: IT Security Specialist
>>>
>>>   Role name: IT Specialist
>>>   Description: IT Specialist
>>>
>>>   Role name: Security Architect
>>>   Description: Security Architect
>>>
>>>   Role name: Smart Proxy Host Manager
>>>   Description: Smart Proxy management
>>>
>>>   Role name: User Administrator
>>>   Description: Responsible for creating Users and Groups
>>> 
>>> Number of entries returned 6
>>> 
>>> [root@ipa-01 ~]# ipa role-show "Smart Proxy Host Manager"
>>>   Role name: Smart Proxy Host Manager
>>>   Description: Smart Proxy management
>>>   Member users: foreman-proxy, foreman-realm-proxy
>>>   Privileges: Smart Proxy Host Management
>>> [root@ipa-01 ~]# ipa privilege-show "Smart Proxy Host Management"
>>>   Privilege name: Smart Proxy Host Management
>>>   Description: Smart Proxy Host Management
>>>   Permissions: Retrieve Certificates from the CA, System: Add DNS
>>> Entries, System: Read DNS Entries, System: Remove DNS Entries, System:
>>> Update DNS
>>>Entries, System: Manage Host Certificates, System:
>>> Manage Host Enrollment Password, System: Manage Host Keytab, System:
>>> Modify Hosts,
>>>System: Remove Hosts, System: Manage Service Keytab,
>>> System: Modify Services, Add Host Enrollment Password
>>>   Granting privilege to roles: Smart Proxy Host Manager
>>> [root@ipa-01 ~]#
>>> [root@ipa-01 ~]# ipa permission-find "Add Host"
>>> -
>>> 3 permissions matched
>>> -
>>>   Permission name: Add Host Enrollment Password
>>>   Granted rights: add
>>>   Effective attributes: userpassword
>>>   Bind rule type: permission
>>>   Subtree: cn=computers,cn=accounts,dc=office,dc=ipa,dc=domain,dc=tld
>>>   Type: host
>>>   Permission flags: V2, SYSTEM
>>>
>>>   Permission name: System: Add Hostgroups
>>>   Granted rights: add
>>>   Bind rule type: permission
>>>   Subtree: cn=hostgroups,cn=accounts,dc=office,dc=ipa,dc=domain,dc=tld
>>>   Type: hostgroup
>>>   Permission flags: V2, MANAGED, SYSTEM
>>>
>>>   Permission name: System: Add Hosts
>>>   Granted rights: add
>>>   Bind rule type: permission
>>>   Subtree: cn=computers,cn=accounts,dc=office,dc=ipa,dc=domain,dc=tld
>>>   Type: host
>>>   Permission flags: V2, MANAGED, SYSTEM
>>> 
>>> Number of entries returned 3
>>> 
>>>
>>>
>>> Can anyone help me out as I'm unsure where this goes wrong.
>>>
>>
>> For 'Add Host Enrollment Password' the granted rights should be write
>> not add.
>>
>> add is for adding entries, not writing attributes.
>>
>> rob
> 

-- 
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] Foreman => Insufficient 'add' privilege to the 'userPassword' attribute

[Rob Crittenden]

Matt . wrote:
> I'm trying to add a host using Foreman to the FreeIPA realm but this
> doesn't work, all things seem to be fine and some other tests from
> people are working:
> 
> The issue is reported here: http://projects.theforeman.org/issues/18850
> 
> 
> My settings are like this:
> 
> 
> [root@ipa-01 ~]# ipa role-find
> ---
> 6 roles matched
> ---
>   Role name: helpdesk
>   Description: Helpdesk
> 
>   Role name: IT Security Specialist
>   Description: IT Security Specialist
> 
>   Role name: IT Specialist
>   Description: IT Specialist
> 
>   Role name: Security Architect
>   Description: Security Architect
> 
>   Role name: Smart Proxy Host Manager
>   Description: Smart Proxy management
> 
>   Role name: User Administrator
>   Description: Responsible for creating Users and Groups
> 
> Number of entries returned 6
> 
> [root@ipa-01 ~]# ipa role-show "Smart Proxy Host Manager"
>   Role name: Smart Proxy Host Manager
>   Description: Smart Proxy management
>   Member users: foreman-proxy, foreman-realm-proxy
>   Privileges: Smart Proxy Host Management
> [root@ipa-01 ~]# ipa privilege-show "Smart Proxy Host Management"
>   Privilege name: Smart Proxy Host Management
>   Description: Smart Proxy Host Management
>   Permissions: Retrieve Certificates from the CA, System: Add DNS
> Entries, System: Read DNS Entries, System: Remove DNS Entries, System:
> Update DNS
>Entries, System: Manage Host Certificates, System:
> Manage Host Enrollment Password, System: Manage Host Keytab, System:
> Modify Hosts,
>System: Remove Hosts, System: Manage Service Keytab,
> System: Modify Services, Add Host Enrollment Password
>   Granting privilege to roles: Smart Proxy Host Manager
> [root@ipa-01 ~]#
> [root@ipa-01 ~]# ipa permission-find "Add Host"
> -
> 3 permissions matched
> -
>   Permission name: Add Host Enrollment Password
>   Granted rights: add
>   Effective attributes: userpassword
>   Bind rule type: permission
>   Subtree: cn=computers,cn=accounts,dc=office,dc=ipa,dc=domain,dc=tld
>   Type: host
>   Permission flags: V2, SYSTEM
> 
>   Permission name: System: Add Hostgroups
>   Granted rights: add
>   Bind rule type: permission
>   Subtree: cn=hostgroups,cn=accounts,dc=office,dc=ipa,dc=domain,dc=tld
>   Type: hostgroup
>   Permission flags: V2, MANAGED, SYSTEM
> 
>   Permission name: System: Add Hosts
>   Granted rights: add
>   Bind rule type: permission
>   Subtree: cn=computers,cn=accounts,dc=office,dc=ipa,dc=domain,dc=tld
>   Type: host
>   Permission flags: V2, MANAGED, SYSTEM
> 
> Number of entries returned 3
> 
> 
> 
> Can anyone help me out as I'm unsure where this goes wrong.
>

For 'Add Host Enrollment Password' the granted rights should be write
not add.

add is for adding entries, not writing attributes.

rob

-- 
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] slapi_ldap_bind - Error: could not send startTLS request

[Rob Crittenden]

lejeczek wrote:
> 
> 
> On 06/03/17 20:11, Rob Crittenden wrote:
>> lejeczek wrote:
>>> hi everyone
>>> I've seemingly finely working domain, I mean it all seem fine to me,
>>> except for:
>>>
>>> [04/Mar/2017:14:26:47.439218725 +] slapi_ldap_bind - Error: could
>>> not send startTLS request: error -1 (Can't contact LDAP server) errno
>>> 107 (Transport endpoint is not connected)
>>> [04/Mar/2017:14:26:47.441155853 +] slapi_ldap_bind - Error: could
>>> not send startTLS request: error -1 (Can't contact LDAP server) errno
>>> 107 (Transport endpoint is not connected)
>>> [04/Mar/2017:14:31:47.454016982 +] slapi_ldap_bind - Error: could
>>> not send startTLS request: error -1 (Can't contact LDAP server) errno
>>> 107 (Transport endpoint is not connected)
>>> [04/Mar/2017:14:31:47.482477473 +] slapi_ldap_bind - Error: could
>>> not send startTLS request: error -1 (Can't contact LDAP server) errno
>>> 107 (Transport endpoint is not connected)
>>> [04/Mar/2017:14:36:46.458508994 +] slapi_ldap_bind - Error: could
>>> not send startTLS request: error -1 (Can't contact LDAP server) errno
>>> 107 (Transport endpoint is not connected)
>>> [04/Mar/2017:14:36:46.479878884 +] slapi_ldap_bind - Error: could
>>> not send startTLS request: error -1 (Can't contact LDAP server) errno
>>> 107 (Transport endpoint is not connected)
>>> [04/Mar/2017:14:41:47.389700728 +] slapi_ldap_bind - Error: could
>>> not send startTLS request: error -1 (Can't contact LDAP server) errno
>>> 107 (Transport endpoint is not connected)
>>> [04/Mar/2017:14:41:47.394379376 +] slapi_ldap_bind - Error: could
>>> not send startTLS request: error -1 (Can't contact LDAP server) errno
>>> 107 (Transport endpoint is not connected)
>>>
>>> being logged quite frequently, as you can see. Setup:
>>>
>>> ipa-client-4.4.0-14.el7.centos.4.x86_64
>>> ipa-client-common-4.4.0-14.el7.centos.4.noarch
>>> ipa-common-4.4.0-14.el7.centos.4.noarch
>>> ipa-python-compat-4.4.0-14.el7.centos.4.noarch
>>> ipa-server-4.4.0-14.el7.centos.4.x86_64
>>> ipa-server-common-4.4.0-14.el7.centos.4.noarch
>>> ipa-server-dns-4.4.0-14.el7.centos.4.noarch
>>>
>>> Replication, users, logins, all seem normal. But above bothers me as I
>>> am afraid it may one day turn out critical and brake stuff down.
>>> This is on the first server that initiated the domain, long time ago.
>>> There is a second server which logs the same, but only a few entries
>>> then goes quiet.
>>> Third server's error log is completely free from this error.
>>>
>>> Would appreciate all help.
>> The CA replication agreements are handled by ipa-csreplica-manage. You
>> may have leftover agreements from previous installs there.
>>
>> rob
>>
> I'm afraid I let over the years for some bits in the domain gone
> haywire. I found this:
> 
> dn: cn=ca,dc=priv,dc=xx.dc=xx.dc=priv,dc=xx,dc=xx,dc=x
> cn: ca
> objectClass: nsContainer
> objectClass: top
> 
> dn: cn=certprofiles,cn=ca,dc=priv,dc=xx.dc=xx.dc=priv,dc=xx,dc=xx,dc=x
> cn: certprofiles
> objectClass: nsContainer
> objectClass: top
> 
> dn: cn=caacls,cn=ca,dc=priv,dc=xx.dc=xx.dc=priv,dc=xx,dc=xx,dc=x
> cn: caacls
> objectClass: nsContainer
> objectClass: top
> 
> dn:
> cn=cas+nsuniqueid=647ed0b1-b70911e6-b84df1c7-2176fa48,cn=ca,dc=priv,dc=xx.dc=xx.dc=priv,dc=xx,dc=xx,dc=x
> cn: cas
> objectClass: nsContainer
> objectClass: top
> 
> dn: cn=cas,cn=ca,dc=priv,dc=xx.dc=xx.dc=priv,dc=xx,dc=xx,dc=x
> cn: cas
> objectClass: nsContainer
> objectClass: top
> 
> dn:
> cn=IECUserRoles,cn=certprofiles,cn=ca,dc=priv,dc=xx.dc=xx.dc=priv,dc=xx,dc=xx,dc=x
> description: User profile that includes IECUserRoles extension from request
> ipaCertProfileStoreIssued: TRUE
> cn: IECUserRoles
> objectClass: ipacertprofile
> objectClass: top
> 
> dn:
> cn=caIPAserviceCert,cn=certprofiles,cn=ca,dc=priv,dc=xx.dc=xx.dc=priv,dc=xx,dc=xx,dc=x
> description: Standard profile for network services
> ipaCertProfileStoreIssued: TRUE
> cn: caIPAserviceCert
> objectClass: ipacertprofile
> objectClass: top
> 
> dn:
> ipaUniqueID=1ea0be16-fc01-11e5-a664-f04da240c1d2,cn=caacls,cn=ca,dc=priv,dc=xx.dc=xx.dc=priv,dc=xx,dc=xx,dc=x
> ipaMemberCertProfile:
> cn=caIPAserviceCert,cn=certprofiles,cn=ca,dc=priv,dc=xx.dc=xx.dc=priv,dc=xx,dc=xx,dc=x
> ipaUniqueID: 1ea0be16-fc01-11e5-a664-f04da240c1d2
> ipaEnabledFlag: TRUE
> hostCategory: all
> objectClass: ipaassociatio

Re: [Freeipa-users] Replica fail to create , all new cert already inside

[Rob Crittenden]

barry...@gmail.com wrote:
> Hi:
> 
> I already done input new cert but ipa-replica-prepare central03.ABC.com
>  (ipa 3.0) it fail with the error as below:
> which "location" I should check the old cert still inside some where
> 
> Below I already input CA / server cert ..and nssdb poting is right
> ..already spent serveral days to check where is it I also try direct use
> pfx for the cert directly but same error comesout...seem it still use
> old cert to compare.
> 
> Any idea ? many thanks
> 
> /var/lib/pki-ca/alias
> /etc/dirsrv/slapd-PKI-IPA/
> /etc/dirsrv/slapd-ABC-COM/
> /etc/httpd/alias/
> /etc/pki/nssdb/
> 
> I use similar commands as below: and follow steps here: https web side
> already using new and dirsvr no error on starting only I cannot do
> replicas .
> 
> https://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP#Procedure_in_IPA_.3C_4.1
> 
> certutil -A -d  /var/lib/pki-ca/alias/ -n 'EXT-CA' -t CT,C,C -a -i
> /root/ca.crt
> 
> 
> ipa : ERRORcert validation failed for "CN=central.ABC.com
> ,O=ABC.COM "
> ((SEC_ERROR_EXPIRED_CERTIFICATE) Peer's Certificate has expired.)
> preparation of replica failed: cannot connect to
> 'https://central.ABCcom:9444/ca/ee/ca/profileSubmitSSLClient':
> (SEC_ERROR_EXPIRED_CERTIFICATE) Peer's Certificate has expired.
> 
> Regards
> 
> Barry
> 
> 

Please stop creating new threads all for the same issue.

Your CA subsystem certs are expired and you'll need to go through the
renewal process to fix that. To do that you need to run `getcert list`
and determine the time period where all the certs are valid, set the
system time to then, restart IPA, restart certmonger.

Knowing that you are using 3rd party certs instead perhaps this doesn't
really matter to you. In any case you probably won't have much luck
mixing and matching certificates between IPA-issued and whatever 3rd
part you're using.

The bottom line is you probably want to get 3rd party certs from
whatever issuer provided the certs for your current master(s), stick
those into PKCS#12 file(s) and pass that to ipa-replica-manage.

So like I said in
https://www.redhat.com/archives/freeipa-users/2017-March/msg00096.html ,
man ipa-replica-manage.

rob

-- 
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 tell if a replica server is also a CA?

[Rob Crittenden]

Zak Wolfinger wrote:
> How can I tell if my FreeIPA 4.2.0 replica servers are also configured to be 
> CAs?
> 
> 

Brute force way is to look in LDAP under
cn=masters,cn=ipa,cn=etc,dc=example,dc=com

$ ldapsearch -LLL -Y GSSAPI -b cn=masters,cn=ipa,cn=etc,dc=example,dc=com dn

The configured services for every master is listed there.

rob

-- 
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] Make Gpg replica fail , where cert store I should update new ?

[Rob Crittenden]

barry...@gmail.com wrote:
> I think I already input all ca cert and server cert

man ipa-replica-prepare

rob

> 
> 
> certutil -d /etc/dirsrv/slapd-PKI-IPA/ -L
> Trust Attributes
> 
> SSL,S/MIME,JAR/XPI
> *.wisers.com <http://wisers.com>  < it is
> the server wild card cert already
> EXT-CA   CT,C,C  the combo cert CA
> ABC.COM <http://ABC.COM> IPA CA 
> CT,,C
> Server-Cert  u,u,u
> 
> 
> When I make replica it comes out error form master server
> central.ABC.com <http://central.ABC.com> ..any I  missing?
> 
> Creating SSL certificate for the dogtag Directory Server
> ipa : ERRORcert validation failed for "CN=central.ABC
> ROR_EXPIRED_CERTIFICATE) Peer's Certificate has expired.)
> preparation of replica failed: cannot connect to
> 'https://central.ABC9444/ca/ee/ca/profileSubmitSSLClient':
> (SEC_ERROR_EXPIRED_CERTIFICATE) Peer's Certificate has expired.
> cannot connect to
> 'https://central.ABC.com:9444/ca/ee/ca/profileSubmitSSLClient':
> (SEC_ERROR_EXPIRED_CERTIFICATE) Peer's Certificate has expired.
>   File "/usr/sbin/ipa-replica-prepare", line 490, in 
> 
> 
> 
> 
> 
> 2017-03-07 21:51 GMT+08:00 Rob Crittenden <rcrit...@redhat.com
> <mailto:rcrit...@redhat.com>>:
> 
> barry...@gmail.com <mailto:barry...@gmail.com> wrote:
> > same as as replica gpg making....Found this cert 2015 expired
> > only,,? but I follow manual here:
> >
> > 
> https://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP#Procedure_in_IPA_.3C_4.1
> 
> <https://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP#Procedure_in_IPA_.3C_4.1>
> >
> 
> <https://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP#Procedure_in_IPA_.3C_4.1
> 
> <https://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP#Procedure_in_IPA_.3C_4.1>>
> 
> If you are using 3rd party certs elsewhere then why not provide 3rd
> party certs for this replica as well?
> 
> It seems like you aren't using the IPA-provided CA at all given its
> certs expired in 2015.
> 
> rob
> 
> >
> > It imported as EXT-CA as Alias rather than sever cert by default...Is
> > there anywhere pointing wrong ?
> >
> > Certificate Nickname Trust
> > Attributes
> >
> > SSL,S/MIME,JAR/XPI
> > *.ABC.com ,,
> > EXT-CA   CT,C,C
> > ABC.COM <http://ABC.COM> <http://ABC.COM> IPA
> > CACT,,C
> > Server-Cert  u,u,u
> >
> >
> > Request ID '20160516111257':
> > status: CA_UNREACHABLE
> > ca-error: Server at https://central.ABC.com/ipa/xml 
> <https://central.ABC.com/ipa/xml> failed
> > request, will retry: 907 (RPC failed at server.  cannot connect to
> > 'https://central.ABC.com:443/ca/agent/ca/displayBySerial
> <https://central.ABC.com:443/ca/agent/ca/displayBySerial>':
> > (SEC_ERROR_UNKNOWN_ISSUER) Peer's Certificate issuer is not 
> recognized.).
> > stuck: no
> > key pair storage:
> > 
> type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS
> > Certificate DB',pinfile='/etc/dirsrv/slapd-PKI-IPA/pwdfile.txt'
> > certificate:
> > 
> type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS
> > Certificate DB'
> > CA: IPA
> > issuer: CN=Certificate Authority,O=ABC.COM
> <http://ABC.COM> <http://ABC.COM>
> > subject: CN=central.ABC.com <http://central.ABC.com>
> <http://central.ABC.com>,O=ABC.COM <http://ABC.COM>
> > <http://ABC.COM>
> > expires: 2015-11-23 08:42:52 UTC
> > key usage:
> > digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
> > eku: id-kp-serverAuth,id-kp-clientAuth
> > pre-save command:
> > post-save command: /usr/lib64/ipa/certmonger/restart_dirsrv 
> PKI-IPA
> > track: y

Re: [Freeipa-users] make a new server and migrate old data

[Rob Crittenden]

barry...@gmail.com wrote:
> Hi:
> 
> I have freeipa 3.0 server ...and want to make a new server ignore any
> cert related.
> 
> eg I clean install a server using default free ipa server cert ..and
> copy dirsrv data to new.
> can I just copy /etc/dirsrv  scheme..username /passwords and groups ?
> 
> Also if I copy these to 4.0 server any issue?

The documentation contains information on how to do IPA to IPA migration
but it will only migrate users and groups.

rob

-- 
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] Make Gpg replica fail , where cert store I should update new ?

[Rob Crittenden]

barry...@gmail.com wrote:
> same as as replica gpg making....Found this cert 2015 expired
> only,,? but I follow manual here:
> 
> https://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP#Procedure_in_IPA_.3C_4.1
> 
>  

If you are using 3rd party certs elsewhere then why not provide 3rd
party certs for this replica as well?

It seems like you aren't using the IPA-provided CA at all given its
certs expired in 2015.

rob

> 
> It imported as EXT-CA as Alias rather than sever cert by default...Is
> there anywhere pointing wrong ?
> 
> Certificate Nickname Trust
> Attributes
> 
> SSL,S/MIME,JAR/XPI
> *.ABC.com ,,
> EXT-CA   CT,C,C
> ABC.COM  IPA
> CACT,,C
> Server-Cert  u,u,u
> 
> 
> Request ID '20160516111257':
> status: CA_UNREACHABLE
> ca-error: Server at https://central.ABC.com/ipa/xml failed
> request, will retry: 907 (RPC failed at server.  cannot connect to
> 'https://central.ABC.com:443/ca/agent/ca/displayBySerial':
> (SEC_ERROR_UNKNOWN_ISSUER) Peer's Certificate issuer is not recognized.).
> stuck: no
> key pair storage:
> type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS
> Certificate DB',pinfile='/etc/dirsrv/slapd-PKI-IPA/pwdfile.txt'
> certificate:
> type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS
> Certificate DB'
> CA: IPA
> issuer: CN=Certificate Authority,O=ABC.COM 
> subject: CN=central.ABC.com ,O=ABC.COM
> 
> expires: 2015-11-23 08:42:52 UTC
> key usage:
> digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
> eku: id-kp-serverAuth,id-kp-clientAuth
> pre-save command:
> post-save command: /usr/lib64/ipa/certmonger/restart_dirsrv PKI-IPA
> track: yes
> auto-renew: yes
> 
> 2017-03-07 19:24 GMT+08:00 Barry  >:
> 
> Same as before I already follow  part < 4.1 as below:
> 
> 
> https://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP#Procedure_in_IPA_.3C_4.1
> 
> 
>  
> comdo cert is new cert /
> It seem I m nearly right HTTP server side can read trust cert
> BUT seem dirsrv still lacking of a ca cert to verify it ./..
> but ca.crt changed to new already and imported
> 
> ABC-COM...[07/Mar/2017:19:17:22 +0800] - SSL alert:
> CERT_VerifyCertificateNow: verify certificate failed for cert
> *.ABC.com - COMODO CA Limited of family
> cn=RSA,cn=encryption,cn=config (Netscape Portable Runtime error
> -8179 - Peer's Certificate issuer is not recognized.)
>
> 
> 2017-03-07 17:16 GMT+08:00 Florence Blanc-Renaud  >:
> 
> Hi,
> 
> In IPA < 4.5, ipa-replica-prepare was using /etc/ipa/ca.crt as
> Certificate Authority, and this file may be outdated. Running
> ipa-certupdate may fix your issue. See [1]
> 
> If it doesn't, you can start by identifying which certificate
> expired with
> $ sudo getcert list | egrep -e 'expires|Request ID|subject'
> 
> HTH,
> Flo
> 
> [1] https://pagure.io/freeipa/issue/6375
> 
> 
> On 03/07/2017 04:14 AM, barry...@gmail.com
>  wrote:
> 
> gpg
> 
> Creating SSL certificate for the Directory Server
> ipa : ERRORcert validation failed for
> "CN=central.ABC.com 
> ,O=ABC.COM 
> "
> ((SEC_ERROR_EXPIRED_CERTIFICATE) Peer's Certificate has
> expired.)
> preparation of replica failed: cannot connect to
> 'https://central.ABC.com:9444/ca/ee/ca/profileSubmitSSLClient 
> ':
> (SEC_ERROR_EXPIRED_CERTIFICATE) Peer's Certificate has expired.
> cannot connect to
> 'https://central.ABC.com:9444/ca/ee/ca/profileSubmitSSLClient 
> ':
> (SEC_ERROR_EXPIRED_CERTIFICATE) Peer's Certificate has expired.
>   File "/usr/sbin/ipa-replica-prepare", line 490, in 
> main()
> 
>

Re: [Freeipa-users] slapi_ldap_bind - Error: could not send startTLS request

[Rob Crittenden]

lejeczek wrote:
> hi everyone
> I've seemingly finely working domain, I mean it all seem fine to me,
> except for:
> 
> [04/Mar/2017:14:26:47.439218725 +] slapi_ldap_bind - Error: could
> not send startTLS request: error -1 (Can't contact LDAP server) errno
> 107 (Transport endpoint is not connected)
> [04/Mar/2017:14:26:47.441155853 +] slapi_ldap_bind - Error: could
> not send startTLS request: error -1 (Can't contact LDAP server) errno
> 107 (Transport endpoint is not connected)
> [04/Mar/2017:14:31:47.454016982 +] slapi_ldap_bind - Error: could
> not send startTLS request: error -1 (Can't contact LDAP server) errno
> 107 (Transport endpoint is not connected)
> [04/Mar/2017:14:31:47.482477473 +] slapi_ldap_bind - Error: could
> not send startTLS request: error -1 (Can't contact LDAP server) errno
> 107 (Transport endpoint is not connected)
> [04/Mar/2017:14:36:46.458508994 +] slapi_ldap_bind - Error: could
> not send startTLS request: error -1 (Can't contact LDAP server) errno
> 107 (Transport endpoint is not connected)
> [04/Mar/2017:14:36:46.479878884 +] slapi_ldap_bind - Error: could
> not send startTLS request: error -1 (Can't contact LDAP server) errno
> 107 (Transport endpoint is not connected)
> [04/Mar/2017:14:41:47.389700728 +] slapi_ldap_bind - Error: could
> not send startTLS request: error -1 (Can't contact LDAP server) errno
> 107 (Transport endpoint is not connected)
> [04/Mar/2017:14:41:47.394379376 +] slapi_ldap_bind - Error: could
> not send startTLS request: error -1 (Can't contact LDAP server) errno
> 107 (Transport endpoint is not connected)
> 
> being logged quite frequently, as you can see. Setup:
> 
> ipa-client-4.4.0-14.el7.centos.4.x86_64
> ipa-client-common-4.4.0-14.el7.centos.4.noarch
> ipa-common-4.4.0-14.el7.centos.4.noarch
> ipa-python-compat-4.4.0-14.el7.centos.4.noarch
> ipa-server-4.4.0-14.el7.centos.4.x86_64
> ipa-server-common-4.4.0-14.el7.centos.4.noarch
> ipa-server-dns-4.4.0-14.el7.centos.4.noarch
> 
> Replication, users, logins, all seem normal. But above bothers me as I
> am afraid it may one day turn out critical and brake stuff down.
> This is on the first server that initiated the domain, long time ago.
> There is a second server which logs the same, but only a few entries
> then goes quiet.
> Third server's error log is completely free from this error.
> 
> Would appreciate all help.

The CA replication agreements are handled by ipa-csreplica-manage. You
may have leftover agreements from previous installs there.

rob

-- 
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] renewing cert and migrating free-ipa 3.1

[Rob Crittenden]

Umarzuki Mochlis wrote:
> At first ip-getcert list hows certificate error
> 
> ca-error: Server failed request, will retry: -504 (libcurl failed to
> execute the HTTP POST transaction, explaining:  Peer's Certificate has
> expired.).
> 
> but after I changed ipa server's date to before expirate date, it shows
> 
> ca-error: Server failed request, will retry: -504 (libcurl failed to
> execute the HTTP POST transaction, explaining:  couldn't connect to
> host).
> 
> when I tried to start ipa with "service ipa start", all services would
> fail, so I need to start one by one
> 
> systemctl start dirsrv@DOMAIN-COM-MY.service
> systemctl status dirsrv@DOMAIN-COM-MY.service
> systemctl start krb5kdc.service
> systemctl status krb5kdc.service
> systemctl start kadmin.service
> systemctl status kadmin.service
> systemctl start ipa_memcached.service
> systemctl status ipa_memcached.service
> systemctl start pki-tomcatd@pki-tomcat.service
> systemctl status pki-tomcatd@pki-tomcat.service
> 
> 
> # tail /var/log/messages
> Jan  3 17:32:26 ipa systemd[1]: Starting PKI Tomcat Server pki-tomcat...
> Jan  3 17:32:29 ipa systemd[1]: Started PKI Tomcat Server pki-tomcat.
> Jan  3 17:33:08 ipa certmonger[476]: 2016-01-03 17:33:08 [476] Server
> failed request, will retry: -504 (libcurl failed to execute the HTTP
> POST transaction, explaining:  couldn't connect to host).
> Jan  3 17:33:12 ipa certmonger[476]: 2016-01-03 17:33:12 [476] Server
> failed request, will retry: -504 (libcurl failed to execute the HTTP
> POST transaction, explaining:  couldn't connect to host).

You want to use the getcert command, not ipa-getcert, to see the CA
subsystem certificates.

What you should do is: getcert list |grep expires

Find a date/time that fits into a period where all certs are valid and
go back in time to then (after stopping ntpd).

That will hopefully fix the ipactl start issue.

Once IPA is restarted, restart certmonger.

rob

-- 
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-install generates bad sssd.conf

[Rob Crittenden]

Harald Dunkel wrote:
> On 03/03/17 10:14, Jakub Hrozek wrote:
>> On Fri, Mar 03, 2017 at 09:56:55AM +0100, Harald Dunkel wrote:
>>>
>>> This is systemd-only?
>>>
>>> Wouldn't it be better to create a working sssd.conf, no matter
>>> what?
>>
>> It is up to whoever is creating the sssd.conf. As I said, the change is
>> backwards-compatible. If you want the services to be started by sssd,
>> then list them in the services line. If you want to have them started on
>> demand and have a simpler configuration, you rely on the systemd services
>> manager.
>>
> 
> Understood. I will try 1.15.1 as soon as possible.
> 
> Reading ipa-client-install it appears to me that the other
> services haven't been omitted on purpose. I have the
> impression that nss and pam have simply been forgotten.
> 
> sssd's ssh service is defined only if ipa-client-install
> is allowed to touch the ssh or sshd configuration, but I
> have *no* idea why there is such a correlation.
> 
> Would somebody mind to look into this?

This is managed by authconfig on Fedora/RHEL systems. Not sure what
Debian does in this regard. Timo?

rob

-- 
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] Kerberos hanging

[Rob Crittenden]

Terry John wrote:
> I have a problem using freeipa version 3.0.0-50 on CentOS release 6.8. The 
> problem manifests itself as no authentication, and no DNS.
> 
> It seems Kerberos just stops responding to requests and requests just get 
> queued up
> # netstat -tuna | grep SYN_RECV
> Active Internet connections (servers and established)
> Proto Recv-Q Send-Q Local Address   Foreign Address 
> State
> tcp0 0   :88IP>:55440 SYN_RECV
> tcp0 0   :88IP>:40076SYN_RECV
> tcp0 0   :88IP>:41525SYN_RECV
> tcp0 0   :88IP>:53958 SYN_RECV
> tcp0 0   :88IP>:54240 SYN_RECV
> 
> Looking at /var/log/krb5kdc.log
> The normal activity of AS_REQ and TGS_REC messages just stops. No error 
> messages. Just  no new messages.

The problem isn't in Kerberos or DNS, ns-slapd is hanging. See this,
http://directory.fedoraproject.org/docs/389ds/FAQ/faq.html#debugging-hangs

rob

-- 
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] New install, unsupported format?

[Rob Crittenden]

Steve Huston wrote:
> Next stage of my testing was to make a replica of the FreeIPA server,
> and I started by doing a 'yum install ipa-server' and then moved on to
> adding the host to the ipaservers group.  This fails every time
> however, with the error:
> 
> ipa: ERROR: cannot connect to
> 'https://ipa.astro.princeton.edu/ipa/json':
> (SEC_ERROR_LEGACY_DATABASE) The certificate/key database is in an old,
> unsupported format.
> 
> Searches on this seem to turn up things like expired certificates, or
> "reboot httpd" (I went ahead and rebooted the whole ipa server), but
> nothing concrete.  Suggestions?  Everything (server and soon-to-be
> replica) running RHEL7.3 with all updates.
> 

See the workaround in https://fedorahosted.org/freeipa/ticket/6575#comment:9

rob

-- 
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] Recommended approach to VM snapshot prior to upgrade

[Rob Crittenden]

Martin Basti wrote:
> 
> 
> On 23.02.2017 00:47, Brian Mathis wrote:
>> I have a 3-node cluster running FreeIPA 4.2 on RHEL 7.2.  I would like
>> to upgrade to RHEL 7.3 / IPA 4.4, and I want to make VM snapshots that
>> I can rollback to in case there are issues.  What is the recommended
>> approach to this?
>>
>> Should services already be started when running the yum update?
> It doesn't matter, updater will stop/start services as needed
> 
>>
>> Can I shut down each ipa service one by one, snapshot, then upgrade? 
>> How would replication be affected if I had to rollback to the older
>> snapshot after other nodes had been upgraded?
> You have to rollback all snapshots for the whole topology and then you
> can start IPA, otherwise replication conflicts may happen.
> So I suggest to have snapshots of all servers before upgrade.
>>
>> Or is it better to shut down all ipa services on all nodes, make
>> snapshots, then perform the upgrade?  Obviously that would bring down
>> the domain during the upgrade, but it would better ensure integrity.
> This is the best for integrity, but in case there is no/low activity on
> servers, then one by one snapshots may work too.

I prefer the shut them all down method if you want a way to get back to
the pre-upgraded state.

Updating one of the masters is going to replicate out a bunch of
changes, so if something goes wrong and you restore that snapshot those
updates have already been replicated out. Would this cause problems?
Ideally no, but you wouldn't have the pre-upgrade systems either.

rob

-- 
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] Dogtag certs did not auto-renew, very stuck!

[Rob Crittenden]

Peter Fern wrote:
> Okay, with much debugging and hoop-jumping, I can say that certmonger on
> Debian/Ubuntu is currently in a rather broken state, at least in a
> server role.
> 
> It links against libcurl3-nss, however on Debian/-derivs there is no
> build of nss-pem, so anything built against libcurl3-nss cannot parse
> PEM formatted certs.  This results in a failure to process the IPA CA
> from the filesystem, causing the certmonger agent to fail verification
> of the server cert, producing the curl 'Error 77 connecting to: Problem
> with the SSL CA cert (path? access rights?)' return, which makes it
> impossible to renew certificates, and resulted in wedging my deployment
> as described.
> 
> Does the FreeIPA issue tracker accept distro-specific reports, or is
> there somewhere more appropriate I should be sending this?  As it
> stands, operating a CA on Debian/Ubuntu will break in painful and
> unexpected fashion, and should be avoided.

Very nice job in tracking this down.

You can certainly open a ticket against freeipa or certmonger but I
think this is more a packaging issue in Debian, et al (although granted
a very non-obvious one).

It's been many moons since I worked on nss-pem but from what I can tell
it should be buildable outside of NSS so can ship as a separate package.
You might try building it locally to see if it resolves the issues for
you. It resides at https://github.com/kdudka/nss-pem

I don't know who does the certmonger packaging, is that you Timo?

rob

> 
> On 21/02/17 23:36, Peter Fern wrote:
>> I don't know why the certs did not auto-renew originally, but now I am
>> very stuck trying to get my CA functional again.  I've tried setting the
>> clock back to a week or two before the certs were due to expire, but I'm
>> still having no luck getting the CA functional.
>>
>> This is a Ubuntu server, so some paths are different to what may be
>> found on RPM-based distros.  Any urgent help would be greatly
>> appreciated - I've been bashing against this for a couple of hours now
>> with no luck, and the hour is getting late.
>>
>> Below is my current (anonymized) `getcert list` of the problem certs,
>> where you will see my current ca-error:
>>
>> Request ID '20160616123036':
>> status: CA_UNREACHABLE
>> ca-error: Error 77 connecting to
>> https://ipaserver.example.com:8443/ca/agent/ca/profileReview: Problem
>> with the SSL CA cert (path? access rights?).
>> stuck: no
>> key pair storage:
>> type=NSSDB,location='/etc/apache2/nssdb',nickname='ipaCert',token='NSS
>> Certificate DB',pinfile='/etc/apache2/nssdb/pwdfile.txt'
>> certificate:
>> type=NSSDB,location='/etc/apache2/nssdb',nickname='ipaCert',token='NSS
>> Certificate DB'
>> CA: dogtag-ipa-ca-renew-agent
>> issuer: CN=Certificate Authority,O=EXAMPLE.COM
>> subject: CN=IPA RA,O=EXAMPLE.COM
>> expires: 2017-02-11 05:52:26 UTC
>> key usage:
>> digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
>> eku: id-kp-serverAuth,id-kp-clientAuth
>> pre-save command: /usr/lib/ipa/certmonger/renew_ra_cert_pre
>> post-save command: /usr/lib/ipa/certmonger/renew_ra_cert
>> track: yes
>> auto-renew: yes
>> Request ID '20160616123427':
>> status: CA_UNREACHABLE
>> ca-error: Error 77 connecting to
>> https://ipaserver.example.com:8443/ca/agent/ca/profileReview: Problem
>> with the SSL CA cert (path? access rights?).
>> stuck: no
>> key pair storage:
>> type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='auditSigningCert
>> cert-pki-ca',token='NSS Certificate DB',pin set
>> certificate:
>> type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='auditSigningCert
>> cert-pki-ca',token='NSS Certificate DB'
>> CA: dogtag-ipa-ca-renew-agent
>> issuer: CN=Certificate Authority,O=EXAMPLE.COM
>> subject: CN=CA Audit,O=EXAMPLE.COM
>> expires: 2017-02-11 05:52:03 UTC
>> key usage: digitalSignature,nonRepudiation
>> pre-save command: /usr/lib/ipa/certmonger/stop_pkicad
>> post-save command: /usr/lib/ipa/certmonger/renew_ca_cert
>> "auditSigningCert cert-pki-ca"
>> track: yes
>> auto-renew: yes
>> Request ID '20160616123428':
>> status: CA_UNREACHABLE
>> ca-error: Error 77 connecting to
>> https://ipaserver.example.com:8443/ca/agent/ca/profileReview: Problem
>> with the SSL CA cert (path? access rights?).
>> stuck: no
>> key pair storage:
>> type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='ocspSigningCert
>> cert-pki-ca',token='NSS Certificate DB',pin set
>> certificate:
>> type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='ocspSigningCert
>> cert-pki-ca',token='NSS Certificate DB'
>> CA: dogtag-ipa-ca-renew-agent
>> issuer: CN=Certificate Authority,O=EXAMPLE.COM
>> subject: CN=OCSP Subsystem,O=EXAMPLE.COM
>> expires: 

Re: [Freeipa-users] support for rfc2307AIX schema in IPA server

[Rob Crittenden]

Iulian Roman wrote:
> Hello,
> 
> Does anybody know if the rfc2307aix schema is supported in IPA server (i
> use red hat IDM version) ? If yes, is there any documentation available
> ? Was it tested ?

No, it isn't supported (it's the first I've ever heard of it). Looking
at the schema I doubt it is something that would ever be fully supported.

rob

> 
> I plan for a big migration and full support of the AIX user attributes
> is one of the prerequisites.


-- 
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] sysaccounts max length

[Rob Crittenden]

Matt . wrote:
> Oh sorry, I thought I did, must have been some conceptmail then :)

You still haven't said what problems you are having.

rob

> 
> 
> 
> 2017-02-20 21:21 GMT+01:00 Rob Crittenden <rcrit...@redhat.com>:
>> Matt . wrote:
>>> Hi All,
>>>
>>> Yes as I stated I see software, multiple, having issues with usernames
>>> larger then 28 characters.
>>
>> You didn't say you had issues you just asked what the max length is.
>>
>> rob
>>
>>>
>>> Cheers,
>>>
>>> Matt
>>>
>>> 2017-02-20 15:53 GMT+01:00 Rob Crittenden <rcrit...@redhat.com>:
>>>> David Kupka wrote:
>>>>> On Sat, Feb 18, 2017 at 03:06:21PM +0100, Matt . wrote:
>>>>>> Hi Guys,
>>>>>>
>>>>>> Does anyone know what the max length is for a sysaccount username is ?
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Matt
>>>>>>
>>>>>> --
>>>>>> 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
>>>>> Hello!
>>>>>
>>>>> From man 8 useradd:
>>>>>
>>>>> Usernames may only be up to 32 characters long.
>>>>
>>>> This is a sysaccount so it has no login capabilities.
>>>>
>>>> I'm not aware of any RFC-specific maximum length for attributes. There
>>>> may be implementation-specific limitations.
>>>>
>>>> Why do you ask? Is something not working?
>>>>
>>>> rob
>>

-- 
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] sysaccounts max length

[Rob Crittenden]

Matt . wrote:
> Hi All,
> 
> Yes as I stated I see software, multiple, having issues with usernames
> larger then 28 characters.

You didn't say you had issues you just asked what the max length is.

rob

> 
> Cheers,
> 
> Matt
> 
> 2017-02-20 15:53 GMT+01:00 Rob Crittenden <rcrit...@redhat.com>:
>> David Kupka wrote:
>>> On Sat, Feb 18, 2017 at 03:06:21PM +0100, Matt . wrote:
>>>> Hi Guys,
>>>>
>>>> Does anyone know what the max length is for a sysaccount username is ?
>>>>
>>>> Thanks,
>>>>
>>>> Matt
>>>>
>>>> --
>>>> 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
>>> Hello!
>>>
>>> From man 8 useradd:
>>>
>>> Usernames may only be up to 32 characters long.
>>
>> This is a sysaccount so it has no login capabilities.
>>
>> I'm not aware of any RFC-specific maximum length for attributes. There
>> may be implementation-specific limitations.
>>
>> Why do you ask? Is something not working?
>>
>> rob

-- 
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] sysaccounts max length

[Rob Crittenden]

David Kupka wrote:
> On Sat, Feb 18, 2017 at 03:06:21PM +0100, Matt . wrote:
>> Hi Guys,
>>
>> Does anyone know what the max length is for a sysaccount username is ?
>>
>> Thanks,
>>
>> Matt
>>
>> -- 
>> 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
> Hello! 
> 
> From man 8 useradd:
> 
> Usernames may only be up to 32 characters long.

This is a sysaccount so it has no login capabilities.

I'm not aware of any RFC-specific maximum length for attributes. There
may be implementation-specific limitations.

Why do you ask? Is something not working?

rob

-- 
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] Cannot install 3rd party certificate

[Rob Crittenden]

Matt . wrote:
> Hi,
> 
> The install seems to be OK this way, but I'm still confused about the
> duplicated and the RootCA.

What does this show?

#3 certutil -L -d /etc/httpd/alias -n COMODORSAAddTrustCA

I'm guessing it will show two certs with different serial numbers, which
means this is a-ok.

rob

> 
> 2017-02-18 14:47 GMT+01:00 Matt . :
>> Hi Florance,
>>
>>
>> I'm actually stil investigating this as the following occurs.
>>
>> I have removed all unneeded certs and installed the 2 intermediates
>> for Comodo and did an ipa-certupdate which results in this:
>>
>> #certutil -L -d /etc/httpd/alias
>>
>> Certificate Nickname Trust Attributes
>>  
>> SSL,S/MIME,JAR/XPI
>>
>> CN=COMODO RSA Domain Validation Secure Server CA,O=COMODO CA
>> Limited,L=Salford,ST=Greater Manchester,C=GB C,,
>> AddTrustExternalCARoot   C,,
>> ipaCert  u,u,u
>> COMODORSAAddTrustCA  C,,
>> COMODORSAAddTrustCA  C,,
>> IPA.MYDOMAIN.TLD IPA CA CT,C,C
>>
>>
>> I'm curious why the COMODORSAAddTrustCA is there twice, if I remove
>> both and start over they are duplicated again. Also the
>> AddTrustExternalCARoot comes back again even when this was not
>> installed anymore as it's not needed.
>>
>> I'm able to install my cert after the update:
>>
>>
>> #certutil -L -d /etc/httpd/alias
>>
>> Certificate Nickname Trust Attributes
>>  
>> SSL,S/MIME,JAR/XPI
>>
>> CN=COMODO RSA Domain Validation Secure Server CA,O=COMODO CA
>> Limited,L=Salford,ST=Greater Manchester,C=GB C,,
>> AddTrustExternalCARoot   C,,
>> ipaCert  u,u,u
>> COMODORSAAddTrustCA  C,,
>> COMODORSAAddTrustCA  C,,
>> IPA.MYDOMAIN.TLD IPA CA CT,C,C
>> CN=*.ipa.mydomain.tld,OU=PositiveSSL Wildcard,OU=Domain Control Validated 
>> u,u,u
>>
>>
>>
>> Now this works great for the WebGui which uses the right Certificate
>> for the ssl connection but ldaps on port 636 seems to use:
>>
>> CN=COMODO RSA Domain Validation Secure Server CA,O=COMODO CA
>> Limited,L=Salford,ST=Greater Manchester,C=GB
>>
>>
>> Do you have any clue about this ?
>>
>> I'm also curious about what IPA syncs between all hosts, it seems to
>> be only the Intermediate certs and not the install domains
>> certificate, this needs to be installed manually after a local
>> #ipa-certupdate on each node ?
>>
>> I hope you can clearify this out.
>>
>>
>> Thanks,
>>
>> Matt
>>
>>
>> 2017-02-17 0:15 GMT+01:00 Matt . :
>>> Hi Flo,
>>>
>>> Sure I can, I will look through the steps closely tomorrow and will
>>> create some lineup here.
>>>
>>> Cheers,
>>>
>>> Matt
>>>
>>> 2017-02-16 23:55 GMT+01:00 Florence Blanc-Renaud :
 On 02/16/2017 09:55 PM, Matt . wrote:
>
> Hi Flo! (if I may call you like that, saves some characters in typing
> but with this extra line it doesn't anymore :))
>
> This works perfectly, thank you very much.
>
 Hi Matt,

 glad I could help. What did you do differently that could explain the
 failure, though? Maybe the cert installation needs some hardening.

 Flo.

> No questions further actually :)
>
> Cheers,
>
> Matt
>
> 2017-02-16 11:17 GMT+01:00 Florence Blanc-Renaud :
>>

-- 
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] Add IP-address client to error-log file

[Rob Crittenden]

Alexandr Slavov wrote:
> Thanks   for your response.
> I was added custom ErrorLogFormat  , but not resolved.
> I think this is python output information.
> 
> Can your have any idea?
> 
> Where can I open ticket about add this?

For the short term https://fedorahosted.org/freeipa/newticket

You need a FAS (Fedora Account) to open one.

rob

> 
> Alexandr Slavov wrote:
> > Hello all.
> > We use CentOS 7 ,FreeIPA 4.4, Apache 2.4
> > We installed audit system like
> > http://www.freeipa.org/page/Centralized_Logging  for monitoring "Who's
> > What's Doing".
> > Audit system parsing /var/log/httpd/error_log and logging to 
> Elasticsearch.
> > 
> > Some string for Remove user from group in FreeIPA from
> > /var/log/httpd/error_log:
> > [Wed Feb 15 03:46:07.381231 2017] [:error] [pid 31732] ipa: INFO:
> > admin-u...@domain.com : batch: 
> group_remove_member(u'somegroup',
> > user=u'someuser'): SUCCESS
> > 
> > Parsed string loaded in Elasticsearch:
> > {
> >   "_index": "logstash-2017.02.15",
> >   "_type": "events",
> >   "_id": "Uniq-ID",
> >   "_score": null,
> >   "_source": {
> > "timestamp": "2017-02-15T03:46:08-06:00",
> > "status": "SUCCESS",
> > "parameters": "'u'somegroup', user=u'someuser'",
> > "action": "group_remove_member",
> > "principal": "admin-u...@domain.com",
> > "pid": "31732",
> > "event.tags": [
> >   "ipa",
> >   "ipa-call",
> >   "batch"
> > ],
> > "host": "server-1",
> > "facility": "local0",
> > "severity": "notice",
> > "tag": "httpderror",
> > "message": " [Wed Feb 15 03:46:07.381231 2017] [:error] [pid 31732]
> > ipa: INFO: admin-u...@domain.com : batch:
> > group_remove_member(u'somegroup', user=u'someuser'): SUCCESS"
> >   },
> >   "fields": {
> > "timestamp": [
> >   1487151968000
> > ]
> >   },
> >   "sort": [
> > 1487151968000
> >   ]
> > }
> > 
> > 
> > But we need add IP-address of admin-u...@domain.com 
>   outputting to
> > error_log.  How can  add IP-address to this error_log file ?
> 
> See https://httpd.apache.org/docs/2.4/mod/core.html#errorlogformat
> 
> You'd have to manually configure this on each master and ensure that it
> survives IPA updates.
> 
> Alternatively you can open a ticket asking IPA to add this.
> 
> rob
> 

-- 
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] Add IP-address client to error-log file

[Rob Crittenden]

Alexandr Slavov wrote:
> Hello all.
> We use CentOS 7 ,FreeIPA 4.4, Apache 2.4
> We installed audit system like
> http://www.freeipa.org/page/Centralized_Logging  for monitoring "Who's
> What's Doing".
> Audit system parsing /var/log/httpd/error_log and logging to Elasticsearch.
> 
> Some string for Remove user from group in FreeIPA from
> /var/log/httpd/error_log:
> [Wed Feb 15 03:46:07.381231 2017] [:error] [pid 31732] ipa: INFO:
> admin-u...@domain.com: batch: group_remove_member(u'somegroup',
> user=u'someuser'): SUCCESS
> 
> Parsed string loaded in Elasticsearch:
> {
>   "_index": "logstash-2017.02.15",
>   "_type": "events",
>   "_id": "Uniq-ID",
>   "_score": null,
>   "_source": {
> "timestamp": "2017-02-15T03:46:08-06:00",
> "status": "SUCCESS",
> "parameters": "'u'somegroup', user=u'someuser'",
> "action": "group_remove_member",
> "principal": "admin-u...@domain.com",
> "pid": "31732",
> "event.tags": [
>   "ipa",
>   "ipa-call",
>   "batch"
> ],
> "host": "server-1",
> "facility": "local0",
> "severity": "notice",
> "tag": "httpderror",
> "message": " [Wed Feb 15 03:46:07.381231 2017] [:error] [pid 31732]
> ipa: INFO: admin-u...@domain.com: batch:
> group_remove_member(u'somegroup', user=u'someuser'): SUCCESS"
>   },
>   "fields": {
> "timestamp": [
>   1487151968000
> ]
>   },
>   "sort": [
> 1487151968000
>   ]
> }
> 
> 
> But we need add IP-address of admin-u...@domain.com  outputting to
> error_log.  How can  add IP-address to this error_log file ?

See https://httpd.apache.org/docs/2.4/mod/core.html#errorlogformat

You'd have to manually configure this on each master and ensure that it
survives IPA updates.

Alternatively you can open a ticket asking IPA to add this.

rob

-- 
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 will not start after certificate renewal

[Rob Crittenden]

Joseph Vandermaas wrote:
> All
>   I have been experiencing some issues with a FreeIPA instance that I 
> maintain. More specifically pki-tomcat has not started since around the time 
> it’s certificate renewed. I submitted this bug report 
> https://fedorahosted.org/freeipa/ticket/6521, however a solution has yet to 
> be found.
>   This installation does have one instresting issue that I believe may be 
> causing it to fail. There are two certificates under cn=EXAMPLE.COM IPA 
> CA,cn=certificates,cn=ipa,cn=etc,dc=example,dc=com. Both of these are valid 
> CA certificates and when I run openssl verify with ether of them as the CA 
> and the new subsystem certificate I get an OK message. I also believe that 
> this issue is causing me not to be able to do a ipa-certupdate on the broken 
> IPA server. Is there a way to to clean this up, should I try renewing the CA 
> certificate and get rid of the old LDAP entries?
> 

What did you do, as exactly as you can remember, to get the certificates
renewed?

rob

-- 
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 issue

[Rob Crittenden]

Giorgio Biacchi wrote:
> Hi list,
> I have this message in the logs:
> 
> Feb  6 16:43:10 dc01 ns-slapd: [06/Feb/2017:16:43:10.157801305 +0100]
> NSMMReplicationPlugin -
> agmt="cn=masterAgreement1-dc02.myorg.local-pki-tomcat" (dc02:389): Data
> required to update replica has been purged from the changelog. The
> replica must be reinitialized.
> 
> But ipa-replica-manage re-initialize --from dc02.myorg.local does not
> fix the problem. Even moving away the changelog directory didn't help..
> 
> I'm running ipa-server-4.4.0-14.el7.centos.4.x86_64 and
> 389-ds-base-1.3.5.10-15.el7_3.x86_64, and setup is:
> 
> #ipa-replica-manage list
> Directory Manager password:
> 
> dc01.myorg.local: master
> dc02.myorg.local: master
> 
> Can someone please tell me which is the correct sequence of actions to
> fix this issue?

The error appears to be the CA replicated data (ref to tomcat in the
agreement) so you need to use ipa-csreplica-manage instead of
ipa-replica-manage.

rob

-- 
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 installation on centos 7

[Rob Crittenden]

amit bhatt wrote:

My QA development setup is running with IPA VERSION: 4.2.0 on centos 7
and I want to install the same version in my production environment as
well.  however when i am running yum install ipa-server i am getting
VERSION: 4.4.0 (package ipa-server-4.4.0-14.el7.centos.4.x86_64) installed.

How can i force IPA server to install 4.2.0 and not 4.4.0?


You'd need to create your own yum repository with the older bits and 
install from there (or push the packages onto your system and do a local 
install).


Note that the IPA packages are tested against the current versions of 
the release which means that some packages may be newer and are 
therefore untested against IPA 4.2.x. Chances are things will work fine 
but there are no guarantees when mixing packages.


rob

--
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] Cannot create replica

[Rob Crittenden]

Jeff Goddard wrote:

My previous install of freeipa became corrupted so I'm starting fresh.
I've got a new Centos 7.2 server set up and installed ipa version s 4.4.
Now I'm trying to set up a replica on another newly created and patched
centos server. The ipa-client-install command completes without issue
but when I try ipa-replica-install --no-host-dns I get up to step 29
setting up the initial replication and it fails. Can someone point me to
the documentation I'm missing or explain what I can do to have success?
Below is the install error log:


I'd check the 389-ds logs on both sides to see if that sheds any light. 
Based on where it blew up the agreements should already have been setup, 
this was just going to force a sync.


rob

--
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] User with rights for only adding hosts

[Rob Crittenden]

Matt . wrote:

Hi,

Is it possible to create a user that can/is allowed (to) only add
hosts using the ipa-client-install ?

Would be nice to know.


Are you asking if it can only add a host in the context of 
ipa-client-install? No.


Or are you asking "Is there a permission I can delegate to add hosts?" 
Yes, I just forget the name and don't have an install in front of me. 
ipa permission-find host should give you a reasonablly short list to 
search through.


I'm imagining that more than that single permission will be required 
though, depending on what it is you want to do (e.g. DNS updates, etc).


rob

--
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-tomcatd fails to start

[Rob Crittenden]

Jeff Goddard wrote:
> Rob,
> 
> I'm getting this error: certutil -M -n "auditSigningCert cert-pki-ca" -d
> /var/lib/pki-ca/alias -t u,u,Pu
> certutil: function failed: SEC_ERROR_LEGACY_DATABASE: The
> certificate/key database is in an old, unsupported format.

The database is in /var/lib/pki/pki-tomcat/alias

I'd start by checking current trust.

Be very wary about documents related to old versions of IPA and proceed
cautiously and understand the changes you may make before applying them.

rob

-- 
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-tomcatd fails to start

[Rob Crittenden]

Jeff Goddard wrote:
> Rob,
> 
> I'm missing something in either the syntax of execution. I'm getting
> this error:
> 
> ldap_modify: Invalid DN syntax (34)
> additional info: invalid dn
> 
> Just as a reminder the version of ipa I'm on is 4.4.

I'd need to see the ldif you're trying to apply.

rob

-- 
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-tomcatd fails to start

[Rob Crittenden]

Jeff Goddard wrote:
> I've followed the instructions related to my error here:
> http://www.freeipa.org/page/Troubleshooting#PKI_Issues but I still
> haven't found a solution.

Look at these instructions
http://www.freeipa.org/page/IPA_2x_Certificate_Renewal

Look only at the ipaCert part, particularly the ou=people part and the
description attribute.

rob

> 
> Jeff
> 
> On Fri, Jan 6, 2017 at 4:05 PM, Jeff Goddard <jgodd...@emerlyn.com
> <mailto:jgodd...@emerlyn.com>> wrote:
> 
> Alan,
> 
> Thank you so VERY much. That resolved the issue for the CA signing
> certificate. However I'm still seeing
> 
> ca-error: Server at
> 
> "https://id-management-1.internal.emerlyn.com:8443/ca/agent/ca/profileProcess
> 
> <https://id-management-1.internal.emerlyn.com:8443/ca/agent/ca/profileProcess>"
> replied: 1: Invalid Credential.
> 
> On multiple requests which have expiration dates in the past. Is
> there something else I need to do?
> 
> Jeff
> 
> On Fri, Jan 6, 2017 at 3:56 PM, Alan Heverley <aheve...@redhat.com
> <mailto:aheve...@redhat.com>> wrote:
> 
> Looks like you need to get the PIN associated to the cert.|
> 
>  # grep 'internal=' /var/lib/pki/pki-tomcat/conf/password.conf |
> 
> Then replace  with the PIN in the command above.
>  
>  # getcert start-tracking -d /etc/pki/pki-tomcat/alias -n
> 'caSigningCert cert-pki-ca' -P  -c dogtag-ipa-ca-renew-agent
> 
> On Fri, Jan 6, 2017 at 3:47 PM, Jeff Goddard
> <jgodd...@emerlyn.com <mailto:jgodd...@emerlyn.com>> wrote:
> 
> I think my problem is deeper than that. I was following this
> 
> guide:http://www.freeipa.org/page/Howto/CA_Certificate_Renewal#Renew_CA_Certificate_on_CA_Servers
> 
> <http://www.freeipa.org/page/Howto/CA_Certificate_Renewal#Renew_CA_Certificate_on_CA_Servers>
> and executed the commands related to having an external CA -
> which we do not have. I now get this message for the CA:
> 
> Request ID '20170101055025':
> status: NEED_KEY_GEN_PIN
> stuck: yes
> key pair storage:
> 
> type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='caSigningCert
> cert-pki-ca',pin set
> certificate:
> 
> type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='caSigningCert
> cert-pki-ca'
> CA: dogtag-ipa-ca-renew-agent
> issuer:
> subject:
> expires: unknown
>     pre-save command:
> post-save command:
> track: yes
> auto-renew: yes
> 
> Is there any way I can recover?
> 
> Jeff
> 
> On Fri, Jan 6, 2017 at 3:43 PM, Rob Crittenden
> <rcrit...@redhat.com <mailto:rcrit...@redhat.com>> wrote:
> 
> Jeff Goddard wrote:
> > I've done this.
> > [root@id-management-1 ipa]# date
> > Sun Jan  1 01:12:27 EST 2017
> >
> >  getcert list give me this as the first entry:
> >
> > Request ID '20150116162120':
> > status: CA_UNREACHABLE
> > ca-error: Server at
> > https://id-management-1.internal.emerlyn.com/ipa/xml
> <https://id-management-1.internal.emerlyn.com/ipa/xml>
> failed request,
> > will retry: 4001 (RPC failed at server.  ipa:
> Certificate Authority not
> > found).
> > stuck: no
> > key pair storage:
> >
> 
> type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS
> > Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt'
> > certificate:
> >
> 
> type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS
> > Certificate DB'
> > CA: IPA
> > issuer: CN=Certificate
> Authority,O=INTERNAL.EMERLYN.COM
> <http://INTERNAL.EMERLYN.COM>
> > <http://INTERNAL.EMERLYN.COM>
> >

Re: [Freeipa-users] pki-tomcatd fails to start

[Rob Crittenden]

Jeff Goddard wrote:
> I've done this.
> [root@id-management-1 ipa]# date
> Sun Jan  1 01:12:27 EST 2017
> 
>  getcert list give me this as the first entry:
> 
> Request ID '20150116162120':
> status: CA_UNREACHABLE
> ca-error: Server at
> https://id-management-1.internal.emerlyn.com/ipa/xml failed request,
> will retry: 4001 (RPC failed at server.  ipa: Certificate Authority not
> found).
> stuck: no
> key pair storage:
> type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS
> Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt'
> certificate:
> type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS
> Certificate DB'
> CA: IPA
> issuer: CN=Certificate Authority,O=INTERNAL.EMERLYN.COM
> <http://INTERNAL.EMERLYN.COM>
> subject: CN=id-management-1.internal.emerlyn.com
> <http://id-management-1.internal.emerlyn.com>,O=INTERNAL.EMERLYN.COM
> <http://INTERNAL.EMERLYN.COM>
> expires: 2017-01-16 16:21:20 UTC
> key usage:
> digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
> eku: id-kp-serverAuth,id-kp-clientAuth
> pre-save command:
> post-save command: /usr/lib64/ipa/certmonger/restart_httpd
> track: yes
> auto-renew: yes
> 
> Restarting cermonger multiple times doesn't help.

Sorry, I missed a step. When you go back in time you first need to
restart IPA. The CA isn't up.

rob

> 
> Jeff
> 
> 
> 
> 
> On Fri, Jan 6, 2017 at 3:23 PM, Rob Crittenden <rcrit...@redhat.com
> <mailto:rcrit...@redhat.com>> wrote:
> 
> Jeff Goddard wrote:
> > Flo,
> >
> > I'm not able to access the link you posted. I did find this thread
> > though
> >
> https://www.redhat.com/archives/freeipa-users/2015-June/msg00144.html 
> <https://www.redhat.com/archives/freeipa-users/2015-June/msg00144.html>
> >
> <https://www.redhat.com/archives/freeipa-users/2015-June/msg00144.html
> <https://www.redhat.com/archives/freeipa-users/2015-June/msg00144.html>>
> > and have set the time back and resubmitted a request. Still no
> success.
> > Any further hints?
> 
> You need to stop ntpd, go back in time to when the certs are valid and
> restart the certmonger service.
> 
> Then use getcert list to monitor things. You really only care about the
> CA subsystem certs are this point.
> 
> You may need to restart certmonger more than once to get all the certs
> updated (you can manually call getcert resubmit -i  if you'd
> prefer).
> 
> Once that is done return to present day, restart ntpd then ipactl
> restart.
> 
> rob
> 
> 
> 
> 
> -- 
> 

-- 
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 add or remove replica after prepare and failed replication

[Rob Crittenden]

Jake wrote:
> Hey All,
> 
> I need to reinstall the replica ipa03.ipa.example.com after
> ipa-server-install --uninstall, however.
> 
> 
> ipa-replica-install replica-info-ipa03.example.com.gpg
> Directory Manager (existing master) password:
> 
> The host ipa03.example.com already exists on the master server.
> You should remove it before proceeding:
> % ipa host-del ipa03.example.com
> ipa.ipapython.install.cli.install_tool(Replica): ERRORThe
> ipa-replica-install command failed. See /var/log/ipareplica-install.log
> for more information
> 
> So on the master I ran:
> 
> ipa-replica-manage del ipa03.ipa.example.com
> ' ipa01.ipa.example.com' has no replication agreement for '
> ipa03.ipa.example.com'
> 
> ipa host-del ipa03.ipa.example.com
> ipa: ERROR: invalid 'hostname': An IPA master host cannot be deleted or
> disabled

Try ipa-replica-manage del ipa03.ipa.example.com --force --cleanup

You may still need to delete the host entry but the first command should
mark it as not a master.

rob

-- 
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-tomcatd fails to start

[Rob Crittenden]

Jeff Goddard wrote:
> Flo,
> 
> I'm not able to access the link you posted. I did find this thread
> though
> https://www.redhat.com/archives/freeipa-users/2015-June/msg00144.html
> 
> and have set the time back and resubmitted a request. Still no success.
> Any further hints?

You need to stop ntpd, go back in time to when the certs are valid and
restart the certmonger service.

Then use getcert list to monitor things. You really only care about the
CA subsystem certs are this point.

You may need to restart certmonger more than once to get all the certs
updated (you can manually call getcert resubmit -i  if you'd prefer).

Once that is done return to present day, restart ntpd then ipactl restart.

rob

-- 
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-tomcatd fails to start

[Rob Crittenden]

Jeff Goddard wrote:
> My environment is freeipa 4.4; centos 7.3. This system was upgraded as
> of yesterday afternoon. I'm unable to start pki-tomcat. The debug log
> show this entry:
> 
> Internal Database Error encountered: Could not connect to LDAP server
> host id-management-1.internal.emerlyn.com
>  port 636 Error
> netscape.ldap.LDAPException: Authentication failed (48)
> at com.netscape.cmscore.dbs.DBSubsystem.init(DBSubsystem.java:676)
> at
> com.netscape.cmscore.apps.CMSEngine.initSubsystem(CMSEngine.java:1169)
> at
> com.netscape.cmscore.apps.CMSEngine.initSubsystems(CMSEngine.java:1075)
> at com.netscape.cmscore.apps.CMSEngine.init(CMSEngine.java:571)
> at com.netscape.certsrv.apps.CMS.init(CMS.java:187)
> at com.netscape.certsrv.apps.CMS.start(CMS.java:1616)
> at
> com.netscape.cms.servlet.base.CMSStartServlet.init(CMSStartServlet.java:114)
> at javax.servlet.GenericServlet.init(GenericServlet.java:158)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> 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)
> 
> 
> I'm able to get a kerberos ticket using kinit but ldap search gives this
> error:
> 
>  ldapsearch -h id-manaement-1.internal.emerlyn.com
>  -x -b
> "cn=CAcert,cn=ipa,cn=etc,dc=internal,dc=emerlyn,dc=com"
> ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
>  
> adding the -d1 debugging tag results in:
> 
> ldap_create
> ldap_url_parse_ext(ldap://id-manaement-1.internal.emerlyn.com
> )
> ldap_sasl_bind
> ldap_send_initial_request
> ldap_new_connection 1 1 0
> ldap_int_open_connection
> ldap_connect_to_host: TCP id-manaement-1.internal.emerlyn.com:389
> 
> ldap_connect_to_host: getaddrinfo failed: Name or service not known
> ldap_err2string
> ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
> 
> I'm able to resolve the hostname via nslookup and /etc/hosts has the
> correct mapping entry.
> 
> I'm kind of lost at this point and could use some help.
> 
> Thanks in advance.

You have a typo in the hostname you're trying to connect to, missing the
'g' in management.

I have a vague memory from other reports of this issue that the problem
may be that the value of the certificate(s) in CS.cfg is 

Re: [Freeipa-users] IPA to IPA migration

[Rob Crittenden]

Timothy Geier wrote:
> This is something I’ve looked at lately and a manual proof of concept I
> just did (using ideas from
> https://www.freeipa.org/page/Howto/Migration#Migrating_from_other_FreeIPA_to_FreeIPA)
> makes it seem theoretically possible (though it looks like, barring the
> migration of the kerberos master key, all enrolled hosts would need to
> use ipa-getkeytab to get a replacement keytab from the new server and
> copy it to /etc/krb5.keytab so that sssd will work properly..the
> alternative is re-enrollment.  All other keytabs in use by other
> applications would have to be similarly replaced).  

Why migrate at all?

> Is https://fedorahosted.org/freeipa/ticket/3656 something that’s coming
> sooner or later to a future version of FreeIPA?  Has anyone done a
> manual migration on a moderate-to-large setup?

Based on where it sits now later seems more probable. I've always seen
this as a way to avert catastrophe, like your only CA just died, not as
a way to move between versions. So it depends on what your use case is,
and if it's a good one, that could affect the timing of the work.

rob

-- 
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] Kerberos authentication failed: kinit: Included profile directory could not be read while initializing Kerberos 5 library

[Rob Crittenden]

Alan Latteri wrote:
> Well on new installs of Cent 7.2, when I do `yum install ipa-client`, that is 
> the version provided.
> Unfortunately, most of our systems have to be on Cent 7.2, not 7.3, and it is 
> out of our control.

Either way it's a bug somewhere in ipa-client, it should require a
minimum version of krb5-libs which provides this file (or explicitly
check for existence of this directory). I opened a ticket on it,
https://fedorahosted.org/freeipa/ticket/6589

rob

> 
> Alan
> 
>> On Jan 3, 2017, at 8:33 PM, Rob Crittenden <rcrit...@redhat.com> wrote:
>>
>> Alan Latteri wrote:
>>> Further investigation.
>>>
>>> On a clean install of CentOS 7.2 with IPA Client 4.4, /etc/krb5.conf.d/ is 
>>> missing, and therefore initial setup will fail unless manual creation of 
>>> /etc/krb5.conf.d/
>>> Maybe the install script for the client can be updated to check for and 
>>> create?
>>
>> Is there a reason you're running 7.3 packages on a 7.2 system? I suspect
>> that is the problem. AFAIU in 7.3 this directory is provided by krb5-libs.
>>
>> Is there some feature you need in the 4.4 client installer on 7.2?
>>
>> rob
>>
>>>
>>> Thanks,
>>> Alan
>>>
>>>> On Jan 3, 2017, at 1:44 PM, Alan Latteri <a...@instinctualsoftware.com> 
>>>> wrote:
>>>>
>>>> Thanks Rob.
>>>>
>>>> /etc/krb5.conf.d/  was in fact missing from the client, which is still on 
>>>> CentOS 7.2 for reasons out of our control.
>>>> Other hosts that are CentOS 7.2 running IPA Client 4.2.0 also do not have 
>>>> the /etc/krb5.conf.d/ directory, but are running fine.  So maybe the 4.4 
>>>> client requires that dir but is not making it on upgrade and the cause of 
>>>> the failure?
>>>>
>>>> Alan
>>>>
>>>>> On Jan 3, 2017, at 1:25 PM, Rob Crittenden <rcrit...@redhat.com> wrote:
>>>>>
>>>>> Alan Latteri wrote:
>>>>>> Log is attached.
>>>>>
>>>>> Look and see if /etc/krb5.conf.d/ and
>>>>> /var/lib/sss/pubconf/krb5.include.d exist and are readable (and check
>>>>> for SELinux AVCs). I'm pretty sure this all runs as root so I doubt
>>>>> filesystem perms are an issue but who knows.
>>>>>
>>>>> You can also brute force things using strace -f to find out exactly what
>>>>> can't be read.
>>>>>
>>>>> rob
>>>>>
>>>>
>>>>
>>>> -- 
>>>> 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
>>>
>>
> 

-- 
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] Kerberos authentication failed: kinit: Included profile directory could not be read while initializing Kerberos 5 library

[Rob Crittenden]

Alan Latteri wrote:
> Log is attached.

Look and see if /etc/krb5.conf.d/ and
/var/lib/sss/pubconf/krb5.include.d exist and are readable (and check
for SELinux AVCs). I'm pretty sure this all runs as root so I doubt
filesystem perms are an issue but who knows.

You can also brute force things using strace -f to find out exactly what
can't be read.

rob

-- 
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 cert automatic renew Failing.

[Rob Crittenden]

Lucas Diedrich wrote:
> OK!, i got it, i just executed the second script:
> 
> "sudo /usr/libexec/ipa/certmonger/renew_ra_cert "subsystemCert
> cert-pki-ca"", and fixed that problem, there another script called
> renew_ra_cert_pre, should i run this too?

No, it should be run BEFORE renew_ra_cert, but since that has executed
successfully there is no point.

rob

> 
> Thanks.
> 
> Em seg, 26 de dez de 2016 às 17:26, Lucas Diedrich
> > escreveu:
> 
> Florence, at first i thought the problem was fixed, but it wasn't
> complety.
> 
> So now, i'm at the CA Master, and when i try to see some
> certificates it prompts me this "[root@ipa2 ~]# ipa cert-show 1
> ipa: ERROR: Certificate operation cannot be completed: EXCEPTION
> (Invalid Credential.)
> "
> The same thing show over the Web Interface, i searched a little bit
> and found that probably it didn't updated the *ipara* user, but
> can't confirm that, any sugestions?
> 
> Thanks,
> 
> Em qui, 22 de dez de 2016 às 11:13, Florence Blanc-Renaud
> > escreveu:
> 
> On 12/22/2016 01:15 PM, Lucas Diedrich wrote:
> > Florence, for some creepy reason the cert from pkidbuser is
> different
> > from subsystem certs, and this pkidbuser is outdated now, but
> i can't
> > manage one way to re-issue it. I had to change the CA server
> because of
> > that, and the Selinux in the old CA Server was disabled, on
> the new one
> > is in Permissive mode but doesn't a warning in
> /var/log/audit/audit.log.
> >
> > This is the pkidbuser cert:
> https://paste.fedoraproject.org/511023/24084431/
> > This is the subsystem cert:
> https://paste.fedoraproject.org/511025/14824085/
> > The ca.subsystem.cert matches the pkidbuser cert.
> >
> > lucasdiedrich.
> >
> Hi,
> 
> you can try to manually call the post-save command that certmonger
> should have issued after putting the certificate in
> /etc/pki/pki-tomcat/alias:
> on the renewal master:
> $ sudo /usr/libexec/ipa/certmonger/stop_pkicad
> $ sudo /usr/libexec/ipa/certmonger/renew_ca_cert "subsystemCert
> cert-pki-ca"
> 
> Then check the journal log that should display the following if
> everything goes well:
> $ sudo journalctl --since today | grep renew_ca_cert
> [...] renew_ca_cert[6478]: Updating entry
> uid=CA-ipaserver.domain.com-8443,ou=people,o=ipaca
> [...] renew_ca_cert[6478]: Updating entry
> uid=pkidbuser,ou=people,o=ipaca
> [...] renew_ca_cert[6478]: Starting pki_tomcatd
> [...] renew_ca_cert[6478]: Started pki_tomcatd
> 
> If the operation does not succeed, you will have to check the LDAP
> server logs in /etc/dirsrv/slapd-DOMAIN/access.
> 
> HTH,
> Flo.
> 
> > Em qui, 22 de dez de 2016 às 06:54, Florence Blanc-Renaud
> >   >> escreveu:
> >
> > On 12/21/2016 07:52 PM, Lucas Diedrich wrote:
> > > Hello guys,
> > >
> > > I'm having some trouble with, whats is happening with my
> server is
> > that
> > > i'm hiting an old BUG
> > > (https://bugzilla.redhat.com/show_bug.cgi?id=1033273).
> Talking to
> > mbasti
> > > over irc he oriented me to send this to the email list.
> > >
> > > The problem is, i got on CA Master, so because of this
> problem the CA
> > > Master certificates couldn't be renewd, so now i
> promoted another
> > master
> > > to be the CA. And the problem still persist.
> > >
> > > This is the certs from my new CA
> > > (https://paste.fedoraproject.org/510617/14823448/),
> > > this is the certs from my old CA
> > > (https://paste.fedoraproject.org/510618/44871148/)
> > > This is the log then i restart pki-tomcat( "CA port 636
> Error
> > > netscape.ldap.LDAPException: Authentication failed (49)")
> > > This is the log from dirsrv when i restart pki-tomcat
> > > (https://paste.fedoraproject.org/510614/23446801/)
> > >
> > > Basically my CA is not working anymore...
> > >
> > > Anyway, i tried lots of thing but couldn't fix this,
> anyone has
> > some idea?
> > >
> > >
> > >
> > Hi,
> >
> > Pki-tomcat is using the LDAP server as a data store,
> meaning that it
> 

Re: [Freeipa-users] IPA Client not able to remove

[Rob Crittenden]

tarak sinha wrote:
> Hi FreeIPA Team,
> 
>  
> 
> I am not able to remove the IPA client host entry from Web UI and
> command line as well. While trying to add it’s showing “Host is already
> exist”. Please give me some suggestion to get rid if this issue.
> 
>  
> 
> #ipa host-del xxx.example.com  --updatedns
> 
> ipa: ERROR: xxx.example.com : host not found
> 
> #ipa host-show xxx.example.com 
> 
> ipa: ERROR: xxx.example.com : host not found

It sounds like it is a replication conflict entry. You can confirm by
doing something like 'ipa host-find xxx.example.com --all' and look at
the DN. If it has nsuniqueid in the DN then it is a conflict entry. See
https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/8.2/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html
but given you want to remove it you can do so via ldapdelete.

rob

-- 
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] Asking for help with crashed freeIPA istance

[Rob Crittenden]

Daniel Schimpfoessl wrote:
> Thanks for getting back to me. 
> 
> getcert list | grep expires shows dates years in the future for all
> certificates
> Inline-Bild 1
> 
> ipactl start --force
> 
> Eventually the system started with:
>  Forced start, ignoring pki-tomcatd Service, continuing normal
> operations.
> 
> systemctl status ipa shows: failed

I don't think this is a certificate problem at all. I think the timing
with your renewal is just coincidence.

Did you change your Directory Manager password at some point?

> 
> ldapsearch -H ldaps://localhost:636 -D "cn=directory manager" -w
> password -b "" -s base
> ldapsearch -H ldaps://localhost:636 -D "cn=directory manager" -w
> *** -b "" -s base
> Inline-Bild 2

You need the -x flag to indicate simple bind.

rob

> The logs have thousands of lines like it, what am I looking for
> specifically?
> 
> Daniel
> 
> 
> 2016-12-20 4:18 GMT-06:00 Florence Blanc-Renaud  >:
> 
> On 12/19/2016 07:15 PM, Daniel Schimpfoessl wrote:
> 
> Good day and happy holidays,
> 
> I have been running a freeIPA instance for a few years and been very
> happy. Recently the certificate expired and I updated it using the
> documented methods. At first all seemed fine. Added a Nagios
> monitor for
> the certificate expiration and restarted the server (single
> server). I
> have weekly snapshots, daily backups (using Amanda on the entire
> disk).
> 
> One day the services relying on IPA failed to authenticate.
> Looking at
> the server the ipa service had stopped. Restarting the service
> fails.
> Restoring a few weeks old snapshot does not start either.
> Resetting the
> date to a few month back does not work either as httpd fails to
> start .
> 
> I am at a loss.
> 
> Here a few details:
> # ipa --version
> VERSION: 4.4.0, API_VERSION: 2.213
> 
> 
> # /usr/sbin/ipactl start
> ...
> out -> Failed to start pki-tomcatd Service
> /var/log/pki/pki-tomcat/ca/debug -> Could not connect to LDAP server
> host ipa.myorg.com  
> port 636 Error
> netscape.ldap.LDAPException: Authentication failed (48)
> 2016-12-19T03:02:16Z DEBUG The CA status is: check interrupted
> due to
> error: Retrieving CA status failed with status 500
> 
> Any help would be appreciated as all connected services are now
> down.
> 
> Thanks,
> 
> Daniel
> 
> 
> 
> 
> Hi Daniel,
> 
> more information would be required to understand what is going on.
> First of all, which certificate did you renew? Can you check with
> $ getcert list
> if other certificates also expired?
> 
> PKI fails to start and the error seems linked to the SSL connection
> with the LDAP server. You may want to check if the LDAP server is
> listening on the LDAPs port:
> - start the stack with
> $ ipactl start --force
> - check the LDAPs port with
> $ ldapsearch -H ldaps://localhost:636 -D "cn=directory manager" -w
> password -b "" -s base
> 
> The communication between PKI and the LDAP server is authenticated
> with the certificate 'subsystemCert cert-pki-ca' located in
> /etc/pki/pki-tomcat/alias, so you may also want to check if it is
> still valid.
> The directory server access logs (in
> /var/log/dirsrv/slapd-DOMAIN-COM/access) would also show the
> connection with logs similar to:
> 
> [...] conn=47 fd=84 slot=84 SSL connection from 10.34.58.150 to
> 10.34.58.150
> [...] conn=47 TLS1.2 128-bit AES; client CN=CA
> Subsystem,O=DOMAIN.COM ; issuer CN=Certificate
> Authority,O=DOMAIN.COM 
> [...] conn=47 TLS1.2 client bound as uid=pkidbuser,ou=people,o=ipaca
> [...] conn=47 op=0 BIND dn="" method=sasl version=3 mech=EXTERNAL
> [...] conn=47 op=0 RESULT err=0 tag=97 nentries=0 etime=0
> dn="uid=pkidbuser,ou=people,o=ipaca"
> 
> 
> 
> HTH,
> Flo
> 
> 
> 
> 

-- 
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 issue / Certificate Authority

[Rob Crittenden]

Christopher Young wrote:
> Ok.  I think I have a 'hint' here, but I could use some help getting this 
> fixed.
> 
> Comparing the two IPA servers, I found the following (modified SOME of
> the output myself):

You're right about the ipaCert. I'd export the renewed cert from your
working server using the same certutil command, just direct it to a file
instead. Then import it into the non-working server and restart the
httpd service. That should do it.

Or you can try restarting certmonger on the non-working server to see if
that triggers it to pull in the updated cert. Theoretically this should
do it as well but given potential past replication problems it is
possible the entry doesn't exist.

getcert list -n ipaCert on each will show some basic information. The
important thing is to see if there is some root cause that will make
this blow up again at renewal time.

rob

> 
> on 'ipa02' (the 'good' one):
> -
> ipa cert-show 1
>   Issuing CA: ipa
>   Certificate: <<>>
>   Subject: CN=Certificate Authority,O=.LOCAL
>   Issuer: CN=Certificate Authority,O=.LOCAL
>   Not Before: Thu Jan 01 06:23:38 2015 UTC
>   Not After: Mon Jan 01 06:23:38 2035 UTC
>   Fingerprint (MD5): a6:aa:88:d4:66:e2:70:c1:e3:8c:37:0b:f3:eb:19:7d
>   Fingerprint (SHA1):
> 11:c2:5a:58:bc:77:55:37:39:9b:13:b1:1a:a2:02:50:be:2e:a0:7f
>   Serial number: 1
>   Serial number (hex): 0x1
>   Revoked: False
> --
> 
> 
> on 'ipa01'
> -
> ipa cert-show 1
> ipa: ERROR: Certificate operation cannot be completed: EXCEPTION
> (Invalid Credential.)
> -
> 
> Thinking about this, I decided to just start checking for
> inconsistencies and I noticed the following:
> 
> ipa02:
> ---
> [root@ipa02 ~]# certutil -L -d /etc/httpd/alias/ -n ipaCert -a |
> openssl x509 -text  | head
> Certificate:
> Data:
> Version: 3 (0x2)
> Serial Number: 268304413 (0xffe001d)
> Signature Algorithm: sha256WithRSAEncryption
> Issuer: O=x.LOCAL, CN=Certificate Authority
> Validity
> Not Before: Nov 23 18:19:31 2016 GMT
> Not After : Nov 13 18:19:31 2018 GMT
> Subject: O=x.LOCAL, CN=IPA RA
> 
> --
> ipa01:
> --
> [root@ipa01 tmp]# certutil -L -d /etc/httpd/alias/ -n ipaCert -a |
> openssl x509 -text  | head
> Certificate:
> Data:
> Version: 3 (0x2)
> Serial Number: 7 (0x7)
> Signature Algorithm: sha256WithRSAEncryption
> Issuer: O=.LOCAL, CN=Certificate Authority
> Validity
> Not Before: Jan  1 06:24:23 2015 GMT
> Not After : Dec 21 06:24:23 2016 GMT
> Subject: O=.LOCAL, CN=IPA RA
> 
> --
> 
> So, it looks like somewhere in the process, the certificate got
> renewed but not updated on 'ipa01'?  I apologize as I'm trying to
> understand this.  I believe that my end goal is probably still the
> same (verify replication and get things working properly on the
> 'ipa01' system.
> 
> Any help is very much appreciated!
> 
> -- Chris
> 
> 
> On Fri, Dec 16, 2016 at 3:35 PM, Christopher Young
>  wrote:
>> I'm hoping to provide enough information to get some help to a very
>> important issue that I'm currently having.
>>
>> I have two IPA servers at a single location that recently had a
>> replication issue that I eventually resolved by reinitializing one of
>> the masters/replicas with one that seemed to be the most 'good'.
>>
>> In any case, somewhere in this process, the new IPA 4.4 was release
>> with/for CentOS 7.3.
>>
>> At this moment, regular replication seems to be working properly (in
>> that I don't have any obvious issues and web interfaces on both
>> systems seem to be consistent for updates EXCEPT when it comes to the
>> certificates).
>>
>> Before I get to the errors, here is the output of some of the commands
>> that I would expect anyone would need:
>>
>> --
>> [root@ipa01 ~]# ipa-replica-manage list
>> ipa01.passur.local: master
>> ipa02.passur.local: master
>> -
>> [root@ipa01 ~]# ipa-replica-manage list -v ipa01.passur.local
>> ipa02.passur.local: replica
>>   last init status: None
>>   last init ended: 1970-01-01 00:00:00+00:00
>>   last update status: Error (0) Replica acquired successfully:
>> Incremental update succeeded
>>   last update ended: 2016-12-16 20:25:40+00:00
>> -
>> [root@ipa01 ~]# ipa-replica-manage list -v ipa02.passur.local
>> ipa01.passur.local: replica
>>   last init status: None
>>   last init ended: 1970-01-01 00:00:00+00:00
>>   last update status: Error (0) Replica acquired successfully:
>> Incremental update succeeded
>>   last update ended: 2016-12-16 20:25:40+00:00
>> -
>> [root@ipa01 ~]# ipa-replica-manage list-ruv
>> Replica Update Vectors:
>> ipa01.passur.local:389: 4
>> ipa02.passur.local:389: 6
>> Certificate Server Replica Update Vectors:
>> ipa02.passur.local:389: 97
>> ipa01.passur.local:389: 96
>> --
>>
>>
>> After the yum updates were 

Re: [Freeipa-users] ACIerrors is httpd log

[Rob Crittenden]

duration=1200 max_age=1481762016 expiration=1481677119.46
> (2016-12-14T00:58:39)
> [Wed Dec 14 00:38:39 2016] [error] ipa: DEBUG: store session:
> session_id=9beb89831ebfca453453ad48feaaa4d0
> start_timestamp=2016-12-14T00:38:39 access_timestamp=2016-12-14T00:38:39
> expiration_timestamp=2016-12-14T00:58:39
> [Wed Dec 14 00:38:39 2016] [error] ipa: DEBUG: Destroyed connection
> context.ldap2
> 
> 
> 
> 
> <http://www.placeiq.com/><http://www.placeiq.com/><http://www.placeiq.com/>
> Jim Richard
> <https://twitter.com/placeiq><https://twitter.com/placeiq><https://twitter.com/placeiq>
> <https://www.facebook.com/PlaceIQ><https://www.facebook.com/PlaceIQ>
> <https://www.linkedin.com/company/placeiq><https://www.linkedin.com/company/placeiq>
> SYSTEM ADMINISTRATOR III
> /(646) 338-8905 / 
> 
> 
> PlaceIQ:Alibaba
> <http://placeiq.com/2016/10/26/the-making-of-a-location-data-industry-milestone/>
> 
> 
> 
> 
>> On Dec 2, 2016, at 5:29 PM, Rob Crittenden <rcrit...@redhat.com
>> <mailto:rcrit...@redhat.com>> wrote:
>>
>> Jim Richard wrote:
>>> Hmm ya. So before I rebuilt anything I thought maybe it was my DNS
>>> records but it looks like that’s not it.
>>>
>>> More background, I used to have sso-109 and sso-110, both CA’s. I
>>> rebuilt sso-110 without CA.
>>>
>>> My DNS is external, BIND on another host.
>>>
>>> Using the following (at the end of the message) host/key issue as an
>>> example. On this host, in sssd.conf, ipa_server and krb5_server values
>>> are both _srv_ so that means they’ll discover from DNS right?
>>>
>>> But in my krb5.conf I have:
>>>
>>> [realms]
>>>  PLACEIQ.NET <http://placeiq.net> <http://placeiq.net> = {
>>>kdc = sso-110.nym1.placeiq.net <http://sso-110.nym1.placeiq.net>
>>> <http://sso-110.nym1.placeiq.net>:88
>>>master_kdc = sso-110.nym1.placeiq.net
>>> <http://sso-110.nym1.placeiq.net>
>>> <http://sso-110.nym1.placeiq.net>:88
>>>admin_server = sso-110.nym1.placeiq.net
>>> <http://sso-110.nym1.placeiq.net>
>>> <http://sso-110.nym1.placeiq.net>:749
>>>default_domain = placeiq.net <http://placeiq.net> <http://placeiq.net>
>>>pkinit_anchors = FILE:/etc/ipa/ca.crt
>>>  }
>>>
>>>
>>> Is there any other IPA related config file that might reference a
>>> host name?
>>>
>>> I’ll include my DNS records at the end here, do they look correct for a
>>> two server setup, one with a CA (sso-109) and the other no CA (sso-110)?
>>>
>>> I never have been sure about the “kerberos-master” entries, what makes
>>> an IPA host a “kerberos master” and is this related to the CA in any way?
>>>
>>> ; ldap servers
>>> _ldap._tcp  IN SRV 0 100 389sso-109.nym1.placeiq.net
>>> <http://sso-109.nym1.placeiq.net>
>>> <http://sso-109.nym1.placeiq.net>.
>>> _ldap._tcp  IN SRV 0 100 389sso-110.nym1.placeiq.net
>>> <http://sso-110.nym1.placeiq.net>
>>> <http://sso-110.nym1.placeiq.net>.
>>>
>>> ;kerberos realm
>>> _kerberos   IN TXT PLACEIQ.NET <http://placeiq.net>
>>> <http://placeiq.net>
>>>
>>> ; kerberos servers
>>> _kerberos._tcp  IN SRV 0 100 88
>>> sso-109.nym1.placeiq.net <http://sso-109.nym1.placeiq.net>
>>> <http://sso-109.nym1.placeiq.net>.
>>> _kerberos._tcp  IN SRV 0 100 88
>>> sso-110.nym1.placeiq.net <http://sso-110.nym1.placeiq.net>
>>> <http://sso-110.nym1.placeiq.net>.
>>>
>>> _kerberos._udp  IN SRV 0 100 88
>>> sso-109.nym1.placeiq.net <http://sso-109.nym1.placeiq.net>
>>> <http://sso-109.nym1.placeiq.net>.
>>> _kerberos._udp  IN SRV 0 100 88
>>> sso-110.nym1.placeiq.net <http://sso-110.nym1.placeiq.net>
>>> <http://sso-110.nym1.placeiq.net>.
>>>
>>> _kerberos-master._tcp   IN SRV 0 100 88
>>> sso-109.nym1.placeiq.net <http://sso-109.nym1.placeiq.net>
>>> <http://sso-109.nym1.placeiq.net>.
>>> _kerberos-master._udp   IN SRV 0 100 88
>>> sso-109.nym1.placeiq.net <http://sso-109.nym1.placeiq.net>
>>> <http://sso-109.nym1.placeiq.net>.
>>> _kerberos-adm._tcp  IN SRV 0 100 749
>>>sso-109.nym1.pla

Re: [Freeipa-users] (no subject)

[Rob Crittenden]

William Muriithi wrote:
> Hello Rob,
> 
> Thanks
> 
>>> After reading the above map page, I was hoping the below command would
>>> list keys on one of the projects map.  It doesn't work though.
>>>
>>> automount --dumpmaps map autofs map tercel
>>>
>>> The info page isn't also any better.  I wonder if someone can explain
>>> the use of these keys by an example.  Would be very grateful
>>>
>>> " "
>>
>> You don't include "map" in the name of the thing. I think you want:
>>
>> automount --dumpmaps sss auto.projects
>>
> Thanks, this indeed is working.  Thanks for clarifying the man page.
> Its however not listing any keys on map created as child to master
> using the flag below.
>  --parentmap=auto.master
> 
> This seem like a bug.  Could this be a corner case that was missed?

Hard to say without seeing your maps and keys.

You could run `ipa automountlocation-tofiles default` to see what IPA
thinks things look like.

rob

-- 
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] (no subject)

[Rob Crittenden]

William Muriithi wrote:
> Hello
> 
> I have indirect map that I would like to list the keys but from
> command line.  I am able to see every key on the home directories map,
> but it display just names for the rest of the maps.
> 
> Looking at the man page, I believe this would be my solution.
> 
>-m, --dumpmaps [ ]
>   With no parameters, list information about the
> configured automounter maps, then exit.
>   If  the  dumpmaps option is given and is followed by two
> parameters, " " then simple "" pairs
> that would be read in
>   by a map read are printed to stdout if the given map
> type and map name are found in the map configuration.
> 
> 
> 
> My maps looks like this:
> 
> Mount point: /projects
> 
> source(s):
> lookup_nss_read_map: reading map sss auto.projects
> do_init: parse(sun): init gathered global options: (null)
> lookup_nss_read_map: reading map files auto.projects
> 
>   instance type(s): sss
>   map: auto.projects
>   quetzal | -fstype=autofs ldap:auto.projects-quetzal
>   tercel | -fstype=autofs ldap:auto.projects-tercel
> 
> 
> After reading the above map page, I was hoping the below command would
> list keys on one of the projects map.  It doesn't work though.
> 
> automount --dumpmaps map autofs map tercel
> 
> The info page isn't also any better.  I wonder if someone can explain
> the use of these keys by an example.  Would be very grateful
> 
> " "

You don't include "map" in the name of the thing. I think you want:

automount --dumpmaps sss auto.projects

rob

-- 
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 Free IPA Client Ubuntu Precise (12.04) authenticating with AD account

[Rob Crittenden]

James Harrison wrote:
> 
> Hi,
> I would prefer not to compile anything. It means we have to maintain the
> package, rather than the distro maintainers.
> 
> Trusty has a completely different set of errors to Precise. 
> 
> Xenial works with no problems.
> 
> I run a script that allows the system to join the IPA domain (the same
> script regardless of Ubuntu distro):
> 
> ( $P_W is read in from stdin)
> 
> ipa-client-install \
>  --server="$IPA_SERVER" \
>  --domain=dns.domain.com \
>  --principal=admin \
>  --password="$P_W" \
>  --preserve-sssd \
>  --mkhomedir \
>  --no-ntp \
>  -U
> 
> 
> Enter (Admins) Password:  
> Confirm Password:
> Hostname: jamestrusty.dns.domain.com
> Realm: IPA.REALM.COM
> DNS Domain: dns.domain.com
> IPA Server: pul-lv-ipa-01.dns.domain.com
> BaseDN: dc=int,dc=worldfirst,dc=com
> 
> Synchronizing time with KDC...
> Dec  8 14:50:58 jamestrusty ntpdate[2448]: ntpdate 4.2.6p5@1.2349-o Wed
> Oct  5 12:35:26 UTC 2016 (1)
> Dec  8 14:50:58 jamestrusty ntpdate[2448]: the NTP socket is in use, exiting
> ...
> ...
> ...
> ...
> ...
> Unable to sync time with IPA NTP server, assuming the time is in sync.
> Please check that 123 UDP port is opened.
> Successfully retrieved CA cert
> Subject: CN=SOMECERT
> Issuer:  CN=SOMECERT
> Valid From:  Wed Mar 12 00:00:00 2014 UTC
> Valid Until: Sun Mar 11 23:59:59 3029 UTC
> 
> Enrolled in IPA realm IPA.REALM.COM
> Created /etc/ipa/default.conf
> New SSSD config will be created
> Configured /etc/sssd/sssd.conf
> Failed to add CA to the default NSS database.
> Installation failed. Rolling back changes.
> Unenrolling client from IPA server
> Unenrolling host failed: Error getting default Kerberos realm:
> Configuration file does not specify default realm.
> 
> Removing Kerberos service principals from /etc/krb5.keytab
> Disabling client Kerberos and LDAP configurations
> Redundant SSSD configuration file /etc/sssd/sssd.conf was moved to
> /etc/sssd/sssd.conf.deleted
> SSSD service could not be stopped
> Client uninstall complete.

The stdout is usually not very helpful, /var/log/ipaclient-install.log
contains the real details.

Still, were I to guess, the required NSS database (and directory)
doesn't exist. This would be located in either /etc/ipa/nssdb or
/etc/pki/nssdb.

rob

> 
> 
> 
> *From:* Lukas Slebodnik 
> *To:* James Harrison 
> *Cc:* "freeipa-users@redhat.com" 
> *Sent:* Thursday, 8 December 2016, 11:22
> *Subject:* Re: [Freeipa-users] Problem with Free IPA Client Ubuntu
> Precise (12.04) authenticating with AD account
> 
> On (07/12/16 18:19), James Harrison wrote:
>>Hi all,
>>
>>I am trying to authenticate an ubuntu Precise (12.06) fully patched
> system. Its enrolled into a FreeIPA server. The following trace is the
> output of syslog auth sssd/*.log and full debug (-ddd) from the sshd
> service.
>>
> Are you able to reproduce with ubuntu 14.04
> and sssd from trusty-updates(1.11.8-0ubuntu0.3)
> You might also consig=der to test sssd-1.13.4 (in ubuntu 16.04)
> or at least 1.12.5-1~trusty1 from ppa
> https://launchpad.net/~sssd
> 
> 
> LS
> 
> 
> 
> 

-- 
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] What should the --hostname option do?

[Rob Crittenden]

Martin Basti wrote:
> 
> 
> On 07.12.2016 15:21, Rob Crittenden wrote:
>> Martin Basti wrote:
>>>
>>> On 07.12.2016 08:48, List dedicated to discussions about use,
>>> configuration and deployment of the IPA server. wrote:
>>>> Hello,
>>>>
>>>> the --hostname option to the installer currently modifies the hostname
>>>> of the machine. In some environments, namely in unprivileged
>>>> containers, that operation is not denied. In some cases, it is
>>>> possible to change the FQDN of the container from outside, for example
>>>> with docker run's -h option. However, in some environments, namely in
>>>> OpenShift, there is not such possibility.
>>>>
>>>> I have found out that disabling the change by turning /bin/hostnamectl
>>>> and /usr/bin/domainname makes ipa-server-install pass while the server
>>>> gets configured with the hostname specified as the parameter to
>>>> --hostname option so it does not seem to be essential for the FQDN to
>>>> change. Of course, some operations might no longer work, like ssh to
>>>> the FreeIPA machine as sshd would need to be set with
>>>> GSSAPIStrictAcceptorCheck no.
>>>>
>>>> I wonder if either change of the --hostname semantics, or some new
>>>> option would be useful, to specify the hostname to be used by the
>>>> FreeIPA software while not touching the configuration of the hostname
>>>> for the machine.
>>>>
>>> I agree that --hostname options should not touch system's hostname, I
>>> don't see reason why application installer should change system
>>> hostname.
>> It was done for sanity because a staggering number of users it seems
>> don't properly set their hostname.
> 
> Then we should have checks and prevent installation, but this needs
> proper design and must cover containers, AWS, etc. to count with various
> scenarios.
> 
>>
>>> I'd start with deprecating current behavior of this option in next
>>> release
>> IMHO it is a pretty significant change of behavior.
> True, so as mentioned later, rather just deprecate this option.

Would be hard to do. Think about something like puppet, it would need to
become version-aware.

> 
>>
>>> As you mentioned we need find what cases can be broken when we will use
>>> different local and external hostname, but anyway we have do this for
>>> containers.
>> Agreed. Something needs to happen, I'm just not convinced it should
>> happen in --hostname. I generally oppose new options but one might be
>> warranted in this case to handle things.
> 
> Maybe --external-hostname or so, noted, we will cover it in design.
> 
>>
>> rob
> 

-- 
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] What should the --hostname option do?

[Rob Crittenden]

Martin Basti wrote:
> 
> 
> On 07.12.2016 08:48, List dedicated to discussions about use,
> configuration and deployment of the IPA server. wrote:
>> Hello,
>>
>> the --hostname option to the installer currently modifies the hostname
>> of the machine. In some environments, namely in unprivileged
>> containers, that operation is not denied. In some cases, it is
>> possible to change the FQDN of the container from outside, for example
>> with docker run's -h option. However, in some environments, namely in
>> OpenShift, there is not such possibility.
>>
>> I have found out that disabling the change by turning /bin/hostnamectl
>> and /usr/bin/domainname makes ipa-server-install pass while the server
>> gets configured with the hostname specified as the parameter to
>> --hostname option so it does not seem to be essential for the FQDN to
>> change. Of course, some operations might no longer work, like ssh to
>> the FreeIPA machine as sshd would need to be set with
>> GSSAPIStrictAcceptorCheck no.
>>
>> I wonder if either change of the --hostname semantics, or some new
>> option would be useful, to specify the hostname to be used by the
>> FreeIPA software while not touching the configuration of the hostname
>> for the machine.
>>
> 
> I agree that --hostname options should not touch system's hostname, I
> don't see reason why application installer should change system hostname.

It was done for sanity because a staggering number of users it seems
don't properly set their hostname.

> I'd start with deprecating current behavior of this option in next release

IMHO it is a pretty significant change of behavior.

> As you mentioned we need find what cases can be broken when we will use
> different local and external hostname, but anyway we have do this for
> containers.

Agreed. Something needs to happen, I'm just not convinced it should
happen in --hostname. I generally oppose new options but one might be
warranted in this case to handle things.

rob

-- 
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] Importing Host Entries from /etc/hosts using sample nis-hosts.sh: Zone name error

[Rob Crittenden]

Robert Kudyba wrote:
> Using the sample script
> 
>  I’m
> trying to use hosts that are in various states meaning they could be
> powered off or disconnected, in our 2 campuses. We maintain a “master”
> /etc/hosts file just to document how are static IP’s are assigned. When
> I try to use the script I get asked for the zone name for each host. We
> use the DNS of the university rather than running one on the FreeIPA
> Fedora 25 server. This is a new install so I can redo this as needed.
> Here’s what I get:
> 
> ./nis-hosts.sh nisname subdomain.ourdomain.edu
> 
> Zone name: 
> ipa: ERROR: 'name' is required
> awk: cmd. line:1: {print $3 "." subdomain.ourdomain.edu
>  "." nisname ".in-addr.arpa."}
> awk: cmd. line:1:  ^ syntax error
> 
> Zone name: subdomain
> ipa: ERROR: DNS is not configured

Looks to me like the DNS component was not configured in IPA so all the
dns-* commands will fail.

> Note I’m using our real domain and subdomain from above. The script is
> below. Can I hard code our domain and/or sub-domain some where in the
> script to get around the Zone name being prompted for each host?
> 
> #!/bin/sh
> # 1 is the nis domain, 2 is the nis master server
> ypcat -d $1-h $2hosts | egrep -v "localhost|127.0.0.1">
> /dev/shm/nis-map.hosts 2>&1 
> 
>  
> 
> IFS=$'\n' 
> forline in$(cat /dev/shm/nis-map.hosts); do 
> IFS=' ' 
> ipaddress=$(echo $line|awk '{print $1}') 
> hostname=$(echo $line|awk '{print $2}') 
> master=$(ipa env xmlrpc_uri |tr -d '[:space:]'|cut -f3 -d:|cut
> -f3 -d/) 
> domain=$(ipa env domain|tr -d '[:space:]'|cut -f2 -d:) 

I'd move these two ipa env commands out of the loop. These values won't
change and will just work to slow down the import.

rob

> if[ $(echo $hostname|grep "\."|wc -l) -eq 0 ]; then 
> hostname=$(echo $hostname.$domain) 
> fi 
> zone=$(echo $hostname|cut -f2- -d.) 
> if[ $(ipa dnszone-show $zone2>/dev/null | wc -l) -eq 0 ]; then 
> ipa dnszone-add
> --name-server=$master--admin-email=root.$master 
> fi 
> ptrzone=$(echo $ipaddress|awk -F. '{print $3 "." $2 "." $1
> ".in-addr.arpa."}')  
> if[ $(ipa dnszone-show $ptrzone2>/dev/null|wc -l) -eq 0 ]; then   
> ipa dnszone-add 
> $ptrzone--name-server=$master--admin-email=root.$master 
> fi 
> # Now create this entry  
> ipa host-add $hostname--ip-address=$ipaddress 
> ipa host-show $hostname 
> done
> 
> 
> 

-- 
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] ACIerrors is httpd log

[Rob Crittenden]

Jim Richard wrote:
> Hmm ya. So before I rebuilt anything I thought maybe it was my DNS
> records but it looks like that’s not it.
> 
> More background, I used to have sso-109 and sso-110, both CA’s. I
> rebuilt sso-110 without CA.
> 
> My DNS is external, BIND on another host.
> 
> Using the following (at the end of the message) host/key issue as an
> example. On this host, in sssd.conf, ipa_server and krb5_server values
> are both _srv_ so that means they’ll discover from DNS right?
> 
> But in my krb5.conf I have:
> 
> [realms]
>   PLACEIQ.NET  = {
> kdc = sso-110.nym1.placeiq.net :88
> master_kdc = sso-110.nym1.placeiq.net
> :88
> admin_server = sso-110.nym1.placeiq.net
> :749
> default_domain = placeiq.net 
> pkinit_anchors = FILE:/etc/ipa/ca.crt
>   }
> 
> 
> Is there any other IPA related config file that might reference a host name?
> 
> I’ll include my DNS records at the end here, do they look correct for a
> two server setup, one with a CA (sso-109) and the other no CA (sso-110)?
> 
> I never have been sure about the “kerberos-master” entries, what makes
> an IPA host a “kerberos master” and is this related to the CA in any way?
> 
> ; ldap servers
> _ldap._tcp  IN SRV 0 100 389sso-109.nym1.placeiq.net
> .
> _ldap._tcp  IN SRV 0 100 389sso-110.nym1.placeiq.net
> .
> 
> ;kerberos realm
> _kerberos   IN TXT PLACEIQ.NET 
> 
> ; kerberos servers
> _kerberos._tcp  IN SRV 0 100 88 sso-109.nym1.placeiq.net
> .
> _kerberos._tcp  IN SRV 0 100 88 sso-110.nym1.placeiq.net
> .
> 
> _kerberos._udp  IN SRV 0 100 88 sso-109.nym1.placeiq.net
> .
> _kerberos._udp  IN SRV 0 100 88 sso-110.nym1.placeiq.net
> .
> 
> _kerberos-master._tcp   IN SRV 0 100 88 sso-109.nym1.placeiq.net
> .
> _kerberos-master._udp   IN SRV 0 100 88 sso-109.nym1.placeiq.net
> .
> _kerberos-adm._tcp  IN SRV 0 100 749sso-109.nym1.placeiq.net
> .
> _kerberos-adm._udp  IN SRV 0 100 749sso-109.nym1.placeiq.net
> .
> 
> _kpasswd._tcp   IN SRV 0 100 464sso-109.nym1.placeiq.net
> .
> _kpasswd._tcp   IN SRV 0 100 464sso-110.nym1.placeiq.net
> .
> 
> _kpasswd._udp   IN SRV 0 100 464sso-109.nym1.placeiq.net
> .
> _kpasswd._udp   IN SRV 0 100 464sso-110.nym1.placeiq.net
> .
> 
> ; CNAME for IPA CA replicas (used for CRL, OCSP)
> ipa-ca  IN A10.1.41.109
> 
> 
> 
> Number of certificates and requests being tracked: 1.
> Request ID '20141110221330':
> status: MONITORING
> ca-error: Server at https://sso-110.nym1.placeiq.net/ipa/xml
> denied our request, giving up: 2100 (RPC failed at server.  Insufficient
> access: not allowed to perform this command).
> stuck: no
> key pair storage:
> type=NSSDB,location='/etc/pki/nssdb',nickname='IPA Machine Certificate -
> phoenix-142.nym1.placeiq.net
> ',token='NSS Certificate DB'
> certificate: type=NSSDB,location='/etc/pki/nssdb',nickname='IPA
> Machine Certificate - phoenix-142.nym1.placeiq.net
> ',token='NSS Certificate DB'
> CA: IPA
> issuer: CN=Certificate Authority,O=PLACEIQ.NET 
> subject: CN=phoenix-142.nym1.placeiq.net
> ,O=PLACEIQ.NET 
> expires: 2016-11-10 22:13:31 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
> 
> 
> 
> We are moving to latest version on RHEL so we’ll have paid support but
> before than, gaining this understanding is massively valuable :)

I'm pretty certain this has nothing to do with servers being removed.
IPA isn't saying it can't find something, it's saying you aren't allowed
to do something.

Why that is the case I don't know. A way to maybe find out would involve
enabling debugging on the server. You can do this by creating
/etc/ipa/server.conf with these contents:

[global]
debug=True

Restart httpd and watch. I'd leave it on just long enough to see the
problem, then turn it off again given you are already 

Re: [Freeipa-users] ACIerrors is httpd log

[Rob Crittenden]

Jim Richard wrote:
> I think I know what the issue is.
> 
> I had 2 IPA servers, both with CA’s
> 
> I dropped one and rebuilt without the CA but a bunch of clients are
> still pointing at this one server that now is without a CA.
> 
> Will rebuild that one with a CA and almost sure that will fix.

I'm rather skeptical of that. Not having a CA should not result in an
ACI error. It should internally forward any cert requests to an IPA
server that does have a CA and relay the result back to the requester.

rob

> 
> <http://www.placeiq.com/><http://www.placeiq.com/><http://www.placeiq.com/>
> Jim Richard
> <https://twitter.com/placeiq><https://twitter.com/placeiq><https://twitter.com/placeiq>
> <https://www.facebook.com/PlaceIQ><https://www.facebook.com/PlaceIQ>
> <https://www.linkedin.com/company/placeiq><https://www.linkedin.com/company/placeiq>
> SYSTEM ADMINISTRATOR III
> /(646) 338-8905 / 
> 
> 
> PlaceIQ:Alibaba
> <http://placeiq.com/2016/10/26/the-making-of-a-location-data-industry-milestone/>
> 
> 
> 
> 
>> On Nov 28, 2016, at 2:39 PM, Rob Crittenden <rcrit...@redhat.com
>> <mailto:rcrit...@redhat.com>> wrote:
>>
>> Jim Richard wrote:
>>> Honestly I’m not even sure if something is not working correctly :)
>>>
>>> All I know is that my httpd, access and krb5 logs are filling up all my
>>> disk space extremely quickly and I have no idea why.
>>>
>>> Centos 6.8 + IPA 3.0
>>>
>>> One master and one replica.
>>>
>>> Are these things related?
>>>
>>> How do I fix, where do I even start?
>>>
>>> Thanks !
>>>
>>> On the replica the httpd log is constantly getting spammed with:
>>>
>>> [Thu Nov 24 05:55:18 2016] [error] ipa: INFO:
>>> host/phoenix-153.nym1.placeiq@placeiq.net
>>> <mailto:host/phoenix-153.nym1.placeiq@placeiq.net>:
>>> cert_request(u’actual cert removed
>> .. , add=True): ACIError
>>>
>>> and on the master the access log is filling up quickly with:
>>>
>>> 10.1.41.110 - - [24/Nov/2016:06:09:54 +] "POST
>>> /ca/agent/ca/displayBySerial HTTP/1.1" 200 10106
>>
>> Looks like certmonger trying to renew the per-client SSL certificate.
>> You can confirm by pulling out the CSR and poking at it with openssl req.
>>
>> On the client you can try running: ipa-getcert list
>>
>> This may show more details on why the request was rejected.
>>
>> rob
> 

-- 
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 fails to start hangs on pki-tomcatd

[Rob Crittenden]

Rob Verduijn wrote:
> 
> 
> 2016-12-01 15:41 GMT+01:00 Rob Crittenden <rcrit...@redhat.com
> <mailto:rcrit...@redhat.com>>:
> 
> Rob Verduijn wrote:
> > Hello,
> >
> > For some reason my ipa server no longer boots.
> > It keeps trying to start pki-tomcat service.
> >
> > Does anybody know where I should start looking to get this fixed ?
> >
> > Rob Verduijn
> >
> > ipactl -d start gives this output:
> > ipa: DEBUG: The CA status is: check interrupted due to error: Command
> > ''/usr/bin/wget' '-S' '-O' '-' '--timeout=30' '--no-check-certificate'
> > 'https://freeipa02.tjako.thuis:8443/ca/admin/ca/getStatus
> <https://freeipa02.tjako.thuis:8443/ca/admin/ca/getStatus>'' returned
> > non-zero exit status 8
> > 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://freeipa02.tjako.thuis:8443/ca/admin/ca/getStatus
> <https://freeipa02.tjako.thuis:8443/ca/admin/ca/getStatus>'
> > ipa: DEBUG: Process finished, return code=8
> > ipa: DEBUG: stdout=
> > ipa: DEBUG: stderr=--2016-12-01 11:06:12--
> > https://freeipa02.tjako.thuis:8443/ca/admin/ca/getStatus
> <https://freeipa02.tjako.thuis:8443/ca/admin/ca/getStatus>
> > Resolving freeipa02.tjako.thuis (freeipa02.tjako.thuis)... 172.16.1.13
> > Connecting to freeipa02.tjako.thuis
> > (freeipa02.tjako.thuis)|172.16.1.13|:8443... connected.
> > HTTP request sent, awaiting response...
> >   HTTP/1.1 500 Internal Server Error
> >   Server: Apache-Coyote/1.1
> >   Content-Type: text/html;charset=utf-8
> >   Content-Language: en
> >   Content-Length: 2134
> >   Date: Thu, 01 Dec 2016 10:06:13 GMT
> >   Connection: close
> > 2016-12-01 11:06:13 ERROR 500: Internal Server Error.
> >
> > There are also some java warnings in the logs, but its java and I can
> > never tell if its a serious error when java gives a warning.
> > Dec  1 09:53:59 freeipa02 server: Dec 01, 2016 9:53:59 AM
> > org.apache.catalina.startup.SetAllPropertiesRule begin
> > Dec  1 09:53:59 freeipa02 server: WARNING:
> > [SetAllPropertiesRule]{Server/Service/Connector} Setting property
> > 'serverCertNickFile' to
> > '/var/lib/pki/pki-tomcat/conf/serverCertNick.conf' did not find a
> > matching property.
> > Dec  1 09:53:59 freeipa02 server: Dec 01, 2016 9:53:59 AM
> > org.apache.catalina.startup.SetAllPropertiesRule begin
> > Dec  1 09:53:59 freeipa02 server: WARNING:
> > [SetAllPropertiesRule]{Server/Service/Connector} Setting property
> > 'passwordFile' to '/var/lib/pki/pki-tomcat/conf/password.conf' did not
> > find a matching property.
> > Dec  1 09:53:59 freeipa02 server: Dec 01, 2016 9:53:59 AM
> > org.apache.catalina.startup.SetAllPropertiesRule begin
> > Dec  1 09:53:59 freeipa02 server: WARNING:
> > [SetAllPropertiesRule]{Server/Service/Connector} Setting property
> > 'passwordClass' to 'org.apache.tomcat.util.net
> <http://org.apache.tomcat.util.net>.jss.PlainPasswordFile'
> > did not find a matching property.
> > Dec  1 09:53:59 freeipa02 server: Dec 01, 2016 9:53:59 AM
> > org.apache.catalina.startup.SetAllPropertiesRule begin
> > Dec  1 09:53:59 freeipa02 server: WARNING:
> > [SetAllPropertiesRule]{Server/Service/Connector} Setting property
> > 'certdbDir' to '/var/lib/pki/pki-tomcat/alias' did not find a matching
> > property.
> > Dec  1 09:53:59 freeipa02 server: Dec 01, 2016 9:53:59 AM
> > org.apache.tomcat.util.digester.SetPropertiesRule begin
> > Dec  1 09:53:59 freeipa02 server: WARNING:
> > [SetPropertiesRule]{Server/Service/Engine/Host} Setting property
> > 'xmlValidation' to 'false' did not find a matching property.
> > Dec  1 09:53:59 freeipa02 server: Dec 01, 2016 9:53:59 AM
> > org.apache.tomcat.util.digester.SetPropertiesRule begin
> > Dec  1 09:53:59 freeipa02 server: WARNING:
> > [SetPropertiesRule]{Server/Service/Engine/Host} Setting property
> > 'xmlNamespaceAware' to 'false' did not find a matching property.
> >
> >
> > I'm running centos7.2 x86_64 with the latest patches applied.
> > some package versions below
> > rpm -qa|egrep "ipa|tomcat"|sort
> > ipa-admintools-4.2.0-15.

Re: [Freeipa-users] ipa fails to start hangs on pki-tomcatd

[Rob Crittenden]

Rob Verduijn wrote:
> Hello,
> 
> For some reason my ipa server no longer boots.
> It keeps trying to start pki-tomcat service.
> 
> Does anybody know where I should start looking to get this fixed ?
> 
> Rob Verduijn
> 
> ipactl -d start gives this output:
> ipa: DEBUG: The CA status is: check interrupted due to error: Command
> ''/usr/bin/wget' '-S' '-O' '-' '--timeout=30' '--no-check-certificate'
> 'https://freeipa02.tjako.thuis:8443/ca/admin/ca/getStatus'' returned
> non-zero exit status 8
> 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://freeipa02.tjako.thuis:8443/ca/admin/ca/getStatus'
> ipa: DEBUG: Process finished, return code=8
> ipa: DEBUG: stdout=
> ipa: DEBUG: stderr=--2016-12-01 11:06:12-- 
> https://freeipa02.tjako.thuis:8443/ca/admin/ca/getStatus
> Resolving freeipa02.tjako.thuis (freeipa02.tjako.thuis)... 172.16.1.13
> Connecting to freeipa02.tjako.thuis
> (freeipa02.tjako.thuis)|172.16.1.13|:8443... connected.
> HTTP request sent, awaiting response...
>   HTTP/1.1 500 Internal Server Error
>   Server: Apache-Coyote/1.1
>   Content-Type: text/html;charset=utf-8
>   Content-Language: en
>   Content-Length: 2134
>   Date: Thu, 01 Dec 2016 10:06:13 GMT
>   Connection: close
> 2016-12-01 11:06:13 ERROR 500: Internal Server Error.
> 
> There are also some java warnings in the logs, but its java and I can
> never tell if its a serious error when java gives a warning.
> Dec  1 09:53:59 freeipa02 server: Dec 01, 2016 9:53:59 AM
> org.apache.catalina.startup.SetAllPropertiesRule begin
> Dec  1 09:53:59 freeipa02 server: WARNING:
> [SetAllPropertiesRule]{Server/Service/Connector} Setting property
> 'serverCertNickFile' to
> '/var/lib/pki/pki-tomcat/conf/serverCertNick.conf' did not find a
> matching property.
> Dec  1 09:53:59 freeipa02 server: Dec 01, 2016 9:53:59 AM
> org.apache.catalina.startup.SetAllPropertiesRule begin
> Dec  1 09:53:59 freeipa02 server: WARNING:
> [SetAllPropertiesRule]{Server/Service/Connector} Setting property
> 'passwordFile' to '/var/lib/pki/pki-tomcat/conf/password.conf' did not
> find a matching property.
> Dec  1 09:53:59 freeipa02 server: Dec 01, 2016 9:53:59 AM
> org.apache.catalina.startup.SetAllPropertiesRule begin
> Dec  1 09:53:59 freeipa02 server: WARNING:
> [SetAllPropertiesRule]{Server/Service/Connector} Setting property
> 'passwordClass' to 'org.apache.tomcat.util.net.jss.PlainPasswordFile'
> did not find a matching property.
> Dec  1 09:53:59 freeipa02 server: Dec 01, 2016 9:53:59 AM
> org.apache.catalina.startup.SetAllPropertiesRule begin
> Dec  1 09:53:59 freeipa02 server: WARNING:
> [SetAllPropertiesRule]{Server/Service/Connector} Setting property
> 'certdbDir' to '/var/lib/pki/pki-tomcat/alias' did not find a matching
> property.
> Dec  1 09:53:59 freeipa02 server: Dec 01, 2016 9:53:59 AM
> org.apache.tomcat.util.digester.SetPropertiesRule begin
> Dec  1 09:53:59 freeipa02 server: WARNING:
> [SetPropertiesRule]{Server/Service/Engine/Host} Setting property
> 'xmlValidation' to 'false' did not find a matching property.
> Dec  1 09:53:59 freeipa02 server: Dec 01, 2016 9:53:59 AM
> org.apache.tomcat.util.digester.SetPropertiesRule begin
> Dec  1 09:53:59 freeipa02 server: WARNING:
> [SetPropertiesRule]{Server/Service/Engine/Host} Setting property
> 'xmlNamespaceAware' to 'false' did not find a matching property.
> 
> 
> I'm running centos7.2 x86_64 with the latest patches applied.
> some package versions below
> rpm -qa|egrep "ipa|tomcat"|sort
> ipa-admintools-4.2.0-15.0.1.el7.centos.19.x86_64
> ipa-client-4.2.0-15.0.1.el7.centos.19.x86_64
> ipa-python-4.2.0-15.0.1.el7.centos.19.x86_64
> ipa-server-4.2.0-15.0.1.el7.centos.19.x86_64
> ipa-server-dns-4.2.0-15.0.1.el7.centos.19.x86_64
> libipa_hbac-1.13.0-40.el7_2.12.x86_64
> python-iniparse-0.4-9.el7.noarch
> python-libipa_hbac-1.13.0-40.el7_2.12.x86_64
> sssd-ipa-1.13.0-40.el7_2.12.x86_64
> tomcat-7.0.54-8.el7_2.noarch
> tomcat-el-2.2-api-7.0.54-8.el7_2.noarch
> tomcat-jsp-2.2-api-7.0.54-8.el7_2.noarch
> tomcatjss-7.1.2-1.el7.noarch
> tomcat-lib-7.0.54-8.el7_2.noarch
> tomcat-servlet-3.0-api-7.0.54-8.el7_2.noarch

The debug log is quite verbose. I find it helpful to note where the
previous log ended, starting and pulling the difference and going line
by line. It sometimes fails in one place which cascades to others this
generally makes it hard to grok.

I'd also run `getcert list` and check to ensure that the CA subsystem
certificates are still valid.

rob

-- 
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] Loss of initial master in multi master setup

[Rob Crittenden]

Martin Babinsky wrote:
> On 12/01/2016 01:28 PM, Neal Harrington | i-Neda Ltd wrote:
>> Hi IPA Gurus,
>>
>>
>> I had a 3 site multi master IPA replication setup (1 office and 2
>> datacentres) with 2 IPA servers at each site. Each server was
>> replicating successfully to 3 other servers (the other local site server
>> and one server at each of the two remote sites). Everything is running
>> on the default packages from CentOS 7.2 and each server is a full
>> replica (ipa-replica-install
>> /var/lib/ipa/replica-info-id-myserver.fqdn.com.gpg  --setup-ca
>> --setup-dns --mkhomedir --forwarder 8.8.8.8)
>>
>>
>> Everything was ticking over nicely until we had notice that the
>> office site was moving on short notice.
>>
>>
>> I successfully created IPA servers at the new site, setup replication
>> again between the new office and the two datacentres that were to remain
>> online, tested and everything worked as expected - unfortunately in the
>> rush I did not have time to properly retire the IPA servers in the old
>> office.
>>
>>
>> The problem this has caused is that I only ever created users in one of
>> the IPA servers in the original office - so only those servers have a
>> DNA range and I am now unable to create new users on the active servers.
>> The original office servers are still in the IPA replication and powered
>> on but offline so potential split brain?
>>
>>
>> I now have two things I would like to know before proceeding:
>>
>>   * Is the best fix here to force remove the original IPA servers and
>> manually add a new dna range significantly different from the
>> original to avoid overlaps?
>>   * Is there anything else I should check? I can't see any issues
>> however did not notice the DNA range until I tried to create a user.
>>
>> Any pointers greatly appreciated.
>>
>>
>> Thanks,
>>
>> Neal.
>>
>>
>>
>>
>>
>>
> 
> Hi Neal,
> 
> If you already disconnected/decomissioned the old masters then I thnk
> the best you can do is option a, i.e. re-set DNA ranges on replicas to
> new values while avioding overlap with old ranges.
> 
> We have an upstream document[1] describing the procedure. Hope it helps.
> 
> Also make sure that you migrated CA renewal and CRL master
> responsibilities to the new replicas, otherwise you may get problems
> with expiring certificates which are really hard to solve. See the
> following guide for details. [2]
> 
> [1] http://www.freeipa.org/page/V3/Recover_DNA_Ranges
> [2] http://www.freeipa.org/page/Howto/Promote_CA_to_Renewal_and_CRL_Master
> 

You may want to look at this too, http://blog-rcritten.rhcloud.com/?p=50

rob

-- 
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