Re: [Freeipa-users] Password history based on age, not count?

[Alexander Bokovoy]

On ke, 03 touko 2017, Patrick Hemmer wrote:

Would it be reasonable to request a feature for FreeIPA to enforce
password history reuse based on age, instead of a count? Meaning
configure FreeIPA to enforce that a password cannot be reused within the
last 1 year? Then we could remove the minimum time between password
changes, and not worry about people cycling through X passwords to be
able to reuse one.

When we were using OpenLDAP for user account management, I wrote an
extension for it to do just that and it was rather convenient (not
having to deal with an annoying min-change-time). The whole
min-time-between-changes, and number-of-passwords-in-history thing has
always seemed like a hack to accomplish the true goal of preventing
users from reusing passwords within a certain amount of time.

Please file a ticket for FreeIPA. We want to eventually move all this
code to 389-ds itself so that its password history check plugin could
support all IPA-related features as well but it is not there yet.

I think password age based checks are a reasonable request.

--
/ 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] Can't make replica with CA due to LDAP 'replication manager' user not found error

[Chris Dagdigian]

Florence Blanc-Renaud wrote:

the issue looks similar to ticket 6766 [1]
Flo.

[1] https://pagure.io/freeipa/issue/6766



Thanks Flo, I agree that this looks like the issue I"m hitting in v4.4 
much appreciated!


I'm gonna be watching this closely, it's nerve wracking knowing that I 
can't use, update or create *any* replica servers at the moment ...


-Chris


--
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] Can't make replica with CA due to LDAP 'replication manager' user not found error

[Florence Blanc-Renaud]

On 05/03/2017 05:16 PM, Chris Dagdigian wrote:



Any guidance for this one?

Summary - this seems to be the fatal error that causes the CA setup on
the replica to fail:

May 03 15:09:09 usaeilidmp002.XXX.org server[3993]: testLDAPConnection:
The specified user cn=Replication Manager
masterAgreement1-usaeilidmp002.XXX.org-pki-tomcat,cn=config does not exist


May 03 15:09:09 usaeilidmp002.XXX.org server[3993]: CMSEngine: init():
password test execution failed for replicationdbwith NO_SUCH_USER.  This
may not be a latest instance.  Ignoring ..


More details ...


Trying to build a replica with CA duties for the first time.

It hangs here during the replica install process:


ipa : DEBUGstderr=
ipa : DEBUGwait_for_open_ports: localhost [8080, 8443]
timeout 300
ipa : DEBUGWaiting until the CA is running
ipa : DEBUGrequest POST
http://usaeilidmp002.XXX.org:8080/ca/admin/ca/getStatus
ipa : DEBUGrequest body ''


However the root cause seems to be that the CA won't start because
something is wrong with an LDAP replication manager user?

When I restart the pki-tomcatd service the replica install STDOUT
refreshes the above status. After the 3rd attempt it triggers the fatal
"CA will not start after 300 seconds" error



From the logs:

# systemctl status pki-tomcatd@pki-tomcat.service
● pki-tomcatd@pki-tomcat.service - PKI Tomcat Server pki-tomcat
   Loaded: loaded (/lib/systemd/system/pki-tomcatd@.service; enabled;
vendor preset: disabled)
   Active: active (running) since Wed 2017-05-03 15:09:04 UTC; 40s ago
  Process: 3843 ExecStop=/usr/libexec/tomcat/server stop (code=exited,
status=1/FAILURE)
  Process: 3880 ExecStartPre=/usr/bin/pkidaemon start %i (code=exited,
status=0/SUCCESS)
 Main PID: 3993 (java)
   CGroup:
/system.slice/system-pki\x2dtomcatd.slice/pki-tomcatd@pki-tomcat.service
   └─3993 /usr/lib/jvm/jre-1.8.0-openjdk/bin/java
-DRESTEASY_LIB=/usr/share/java/resteasy-base
-Djava.library.path=/usr/lib64/nuxwdog-jni -classpath /usr/share/...

May 03 15:09:08 usaeilidmp002.XXX.org server[3993]:
SSLAuthenticatorWithFallback: Setting container
May 03 15:09:09 usaeilidmp002.XXX.org server[3993]:
SSLAuthenticatorWithFallback: Initializing authenticators
May 03 15:09:09 usaeilidmp002.XXX.org server[3993]:
SSLAuthenticatorWithFallback: Starting authenticators
May 03 15:09:09 usaeilidmp002.XXX.org server[3993]:
CMSEngine.initializePasswordStore() begins
May 03 15:09:09 usaeilidmp002.XXX.org server[3993]:
CMSEngine.initializePasswordStore(): tag=internaldb
May 03 15:09:09 usaeilidmp002.XXX.org server[3993]: testLDAPConnection
connecting to usaeilidmp002.XXX.org:389
May 03 15:09:09 usaeilidmp002.XXX.org server[3993]:
CMSEngine.initializePasswordStore(): tag=replicationdb
May 03 15:09:09 usaeilidmp002.XXX.org server[3993]: testLDAPConnection
connecting to usaeilidmp002.XXX.org:389
May 03 15:09:09 usaeilidmp002.XXX.org server[3993]: testLDAPConnection:
The specified user cn=Replication Manager
masterAgreement1-usaeilidmp002.XXX...not exist
May 03 15:09:09 usaeilidmp002.XXX.org server[3993]: CMSEngine: init():
password test execution failed for replicationdbwith NO_SUCH_USER.  This
may not...noring ..
Hint: Some lines were ellipsized, use -l to show in full.







Hi,

the issue looks similar to ticket 6766 [1]
Flo.

[1] https://pagure.io/freeipa/issue/6766

--
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] Can't make replica with CA due to LDAP 'replication manager' user not found error

[Chris Dagdigian]

Standa Laznicka wrote:
You can, but you probably won't be able to install a CA replica on 
them (you have to leave out the --setup-ca option). In the meantime, 
you can create replicas without CA replication and when the Dogtag/DS 
guys solve the problem, you can run ipa-ca-install on those to setup 
CA replication there as well. 


Appreciate the attention this is getting!

My testing from yesterday shows that all replication is broken for me 
due to this 'replication manager' user not existing in LDAP so I may be 
hit by something in addition to the dogtag issue


I have two  servers that are out of sync with each other

 - Manual force update fails
 - Manual re-initialization fails
 - Installing a new IPA server without CA-service claims to work but no 
actual updates transfer


As far as I can tell all of the failures are due to an LDAP access issue 
where the logs talk about a replication-agreement-specific LDAP user not 
existing.


Example From Replica:

# ipa-replica-manage -v re-initialize --from usaeilidmp001.redactedidm.org
ipa: INFO: Setting agreement 
cn=meTousaeilidmp002.redactedidm.org,cn=replica,cn=dc\=redactedidm\,dc\=org,cn=mapping 
tree,cn=config schedule to 2358-2359 0 to force synch
ipa: INFO: Deleting schedule 2358-2359 0 from agreement 
cn=meTousaeilidmp002.redactedidm.org,cn=replica,cn=dc\=redactedidm\,dc\=org,cn=mapping 
tree,cn=config

Update in progress, 14 seconds elapsed

# [usaeilidmp001.redactedidm.org] reports: Update failed! Status: [-2  - 
LDAP error: Local error]




dirsirv error logs from Master:

04/May/2017:12:20:08.531621754 +] slapi_ldap_bind - Error: could not 
bind id [cn=Replication Manager 
cloneAgreement1-usaeilidmp002.redactedidm.org-pki-tomcat,ou=csusers,cn=config] 
authentication mechanism [SIMPLE]: error 32 (No such object) errno 0 
(Success)
[04/May/2017:12:20:10.071619724 +] slapi_ldap_bind - Error: could 
not bind id [cn=Replication Manager 
cloneAgreement1-deawilidmp001.redactedidm.org-pki-tomcat,ou=csusers,cn=config] 
authentication mechanism [SIMPLE]: error 32 (No such object) errno 0 
(Success)
[04/May/2017:12:20:11.074340742 +] set_krb5_creds - Could not get 
initial credentials for principal [ldap/usaeilidmp001.redactedidm.org@] 
in keytab [FILE:/etc/dirsrv/ds.keytab]: -1765328203 (Key table entry not 
found)
[04/May/2017:12:20:35.078730934 +] set_krb5_creds - Could not get 
initial credentials for principal [ldap/usaeilidmp001.redactedidm.org@] 
in keytab [FILE:/etc/dirsrv/ds.keytab]: -1765328203 (Key table entry not 
found)
[04/May/2017:12:21:23.083737475 +] set_krb5_creds - Could not get 
initial credentials for principal [ldap/usaeilidmp001.redactedidm.org@] 
in keytab [FILE:/etc/dirsrv/ds.keytab]: -1765328203 (Key table entry not 
found)






Regards,
Chris



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

[Petr Vobornik]

On 05/04/2017 12:41 AM, Ian Harding wrote:

Is there any way this can be made to work?  This server does not exist
in real life or seemingly in FreeIPA, but a ghost of it does.

ianh@vm-ian-laptop:~$ ipa server-find freeipa-dal.bpt.rocks

1 IPA server matched

  Server name: freeipa-dal.bpt.rocks
  Min domain level: 0
  Max domain level: 0

Number of entries returned 1

ianh@vm-ian-laptop:~$ ipa server-del freeipa-dal.bpt.rocks
Removing freeipa-dal.bpt.rocks from replication topology, please wait...
ipa: ERROR: freeipa-dal.bpt.rocks: server not found
ianh@vm-ian-laptop:~$ ipa server-del freeipa-dal.bpt.rocks --force
Removing freeipa-dal.bpt.rocks from replication topology, please wait...
ipa: ERROR: freeipa-dal.bpt.rocks: server not found
ianh@vm-ian-laptop:~$ ipa server-del freeipa-dal.bpt.rocks --force
--continue
Removing freeipa-dal.bpt.rocks from replication topology, please wait...
ipa: WARNING: Forcing removal of freeipa-dal.bpt.rocks
-
Deleted IPA server ""
-
  Failed to remove: freeipa-dal.bpt.rocks
ianh@vm-ian-laptop:~$

- Ian



This looks like a bug to me.

Probably some LDAP search ended with "not found" result which then was 
incorrectly interpreted as "server not found".


To know where the issue is it would help switch IPA framework on server 
to debug mode [1] and provide httpd/error_log and dirsrv/$domain/access 
log from time of execution of the command.


[1] https://www.freeipa.org/page/Troubleshooting#Administration_Framework

--
Petr Vobornik


--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] I think I lost my CA...

[Petr Vobornik]

On 04/28/2017 02:57 PM, Bret Wortman wrote:

Flo,

I did find that issue and made those corrections to our /etc/hosts file,
but the problem persists.

Thanks for the idea!


after the change did you restart pki?




Bret



On 04/27/2017 03:42 AM, Florence Blanc-Renaud wrote:

On 04/26/2017 04:33 PM, Bret Wortman wrote:

So I can see my certs using cert-find, but can't get details using
cert-show or add new ones using cert-request.

# ipa cert-find
:
--
Number of entries returned 385
--
# ipa cert-show 895
ipa: ERROR: Certificate operation cannot be completed: Unable to
communicate with CMS (503)
# ipa cert-show 1 (which does not exist)
ipa: ERROR: Certificate operation cannot be completed: Unable to
communicate with CMS (503)
# ipa cert-status 895
ipa: ERROR: Certificate operation cannot be completed: Unable to
communicate with CMS (503)
#

Is this an IPV6 thing? Because ipactl shows everything green and
certmonger is running.


Hi Bret,

the issue looks similar to https://pagure.io/freeipa/issue/6575 and
https://pagure.io/dogtagpki/issue/2570 which were IPv6 related. Note
that IPv6 must be enabled on the machine but IPA does not require an
IPv6 address to be configured (except for the loopback).

You can check the following:
- is PKI listening to port 8009 on IPv6 or IPv4 interface?
sudo netstat -tunpl | grep 8009
tcp6   0  0 127.0.0.1:8009  :::* LISTEN 10749/java

- /etc/pki/pki-tomcat/server.xml defines a redirection from port 8009
to 8443, and the "address" part is important:


In the above example, it will be using localhost which can resolve
either to IPv4 or IPv6.

- /etc/hosts must define the loopback addresses with
127.0.0.1   localhost localhost.localdomain localhost4
localhost4.localdomain4
::1 localhost localhost.localdomain localhost6
localhost6.localdomain6

HTH,
Flo.

Bret


On 04/26/2017 09:03 AM, Bret Wortman wrote:


Digging still deeper:

# ipa cert-request f.f --principal=HTTP/`hostname`@DAMASCUSGRP.COM
ipa: ERROR: Certificate operation cannot be completed: Unable to
communicate with CMS (503)

Looks like this is an HTTP error; so is it possible that my IPA thinks
it has a CA but there's no CMS available?


On 04/26/2017 08:41 AM, Bret Wortman wrote:


Using the firefox debugger, I get these errors when trying to pop up
the New Certificate dialog:

Empty string passed to getElementById(). (5)
jquery.js:4:1060
TypeError: u is undefined
app.js:1:362059
Empty string passed to getElementById(). (5)
jquery.js:4:1060
TypeError: t is undefined
app.js:1:217432

I'm definitely not a web kind of guy so I'm not sure if this is
helpful or not. This is on 4.4.0, API Version 2.213.


Bret


On 04/26/2017 08:35 AM, Bret Wortman wrote:


Good news. One of my servers _does_ have CA installed. So why does
"Action -> New Certificate" not do anything on this or any other
server?


Bret


On 04/25/2017 02:52 PM, Bret Wortman wrote:


I recently had to upgrade all my Fedora IPA servers to C7. It went
well, and we've been up and running nicely on 4.4.0 on C7 for the
past month or so.

Today, someone came and asked me to generate a new certificate for
their web server. All was good until I went to the IPA UI and tried
to perform Actions->New Certificate, which did nothing. I tried
each of our 3 servers in turn. All came back with no popup window
and no error, either.

I suspect the problem might be that we no longer have a CA server
due to the method I used to upgrade the servers. I likely missed a
"--setup-ca" in there somewhere, so my rolling update rolled over
the CA.

What's my best hope of recovery? I never ran this before, so I'm
not sure if this shows that I'm missing a CA or not:

# ipa ca-find

1 CA matched

  Name: ipa
  Description IPA CA
  Authority ID: 3ce3346[...]
  Subject DN: CN=Certificate Authority, O=DAMASCUSGRP.COM
  Issuer DN: CN=Certificate Authority,O=DAMASCUSGRP.COM

Number of entries returned 1

# ipa ca-add dg --desc "Damascus Group" --subject "CN=DG CA,
O=DAMASCUSGRP.COM"
ipa: ERROR: Failed to authenticate to CA REST API
# klist
Ticket cache: KEYRING:persistent:0:0
Default principal: ad...@damascusgrp.com

Valid starting  Expires  Service principal
04/25/2017 18:48:26 04/26/2017 18:48:21
krbtgt/damascusgrp@damascusgrp.com
#


What's my best path of recovery?

--
*Bret Wortman*
The Damascus Group
























--
Petr Vobornik

Associate Manager, Engineering, Identity Management
Red Hat

--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] 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

[Freeipa-users] Getting a certificate for an alias

[Steve Huston]

I'm trying to use certmonger to get an SSL certificate on a web host
which has an alias.  I added the alias as a principal alias to the
host record in FreeIPA, and I added the service as well with the
actual hostname and the alias.  However every time certmonger contacts
the CA, the request is rejected with "The service principal for
subject alt name ... does not exist" (or earlier, another similar
error which has now been lost to the scrollback).

hostname: coathook.astro.princeton.edu
Principal alias: host/coathook.astro.princeton@astro.princeton.edu
Principal alias: host/puppet.astro.princeton@astro.princeton.edu

Principal alias: HTTP/coathook.astro.princeton@astro.princeton.edu
Principal alias: HTTP/puppet.astro.princeton@astro.princeton.edu
Service: HTTP
Host Name: coathook.astro.princeton.edu

ipa-getcert request -k /etc/pki/tls/private/puppetexplorer.key -f
/etc/pki/tls/certs/puppetexplorer.crt -D puppet.astro.princeton.edu -N
CN=coathook.astro.princeton.edu,O=ASTRO.PRINCETON.EDU -K
HTTP/coathook.astro.princeton@astro.princeton.edu -C
'/usr/sbin/apachectl graceful'

When I check with ipa-getcert list, I find:
ca-error: Server at https://ipa.astro.princeton.edu/ipa/xml
failed request, will retry: 4001 (RPC failed at server.  The service
principal for subject alt name puppet.astro.princeton.edu in
certificate request does not exist).

Other attempts used the CN of puppet, and the Kerberos principal of
puppet as well, and they also failed but with the slightly different
error (I believe it was that the host does not exist).

So how does one create a certificate for an alias on a host?

-- 
Steve Huston - W2SRH - Unix Sysadmin, PICSciE/CSES & Astrophysical Sci
  Princeton University  |ICBM Address: 40.346344   -74.652242
345 Lewis Library   |"On my ship, the Rocinante, wheeling through
  Princeton, NJ   08544 | the galaxies; headed for the heart of Cygnus,
(267) 793-0852  | headlong into mystery."  -Rush, 'Cygnus X-1'

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

[Freeipa-users] DNS forwarding issue

[William Muriithi]

Hello,

I have a problem with Samba setup that I haven't been able to overcome for
months.  I am trying to setup samba on RHEL 7 using SSSD instead of winbind

Currently, I have a one way trust between the production Active directory
and productin IPA.  I have users on IPA and Active directory. For example,
I have an account called will...@activedirectory.example.com and
will...@ipa.example.com.  To get sharing working, I have created a posix
group that now have of the above users.  The intent is, I should be able to
write to my Linux home user irrespective of what account I log in with.


[homes]
comment = Home Directories
path = /home/william
browseable = yes
writeable = yes
valid users = @william_posix_group


 From any of the IPA clients, samba seem to work fine.  I can login with
samba client, delete, list and do anything.  With klist, I do see both the
CIFS and Linux host ticket.

>From Windows though, it don't work.  I see that the Windows system did
actually get the host ticket for the server running samba,  the Windows
hots ticket  but the CIFS ticket is missing.

With that background, I have setup a dummy active directory called
test.local.  Essentially, I intend to destroy it once I verify that the
behaviour is consistent with the production active directory.  I am however
stuck with DNS setup, and can't therefore establish trust between
production IPA and dummy active directory.

Would you know what I could be doing wrong with from the logs below?

[root@lithium ~]# ipa dnsforwardzone-add test.local.
--forwarder=192.168.11.56 --forward-policy=first
Server will check DNS forwarder(s).
This may take some time, please wait ...
ipa: WARNING: DNSSEC validation failed: record 'test.local. SOA' failed
DNSSEC validation on server 192.168.20.1.
Please verify your DNSSEC configuration or disable DNSSEC validation on all
IPA servers.
  Zone name: test.local.
  Active zone: TRUE
  Zone forwarders: 192.168.11.56
  Forward policy: first
[root@lithium ~]# dig  +short -t SRV _kerberos._udp.dc._msdcs.test.local
[root@lithium ~]# dig @192.168.11.56  +short -t SRV
_kerberos._udp.dc._msdcs.test.local
0 100 88 server.test.local.
[root@lithium ~]#


Regards,
William
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] LDAP Conflicts

[Mark Reynolds]

On 05/04/2017 10:20 AM, James Harrison wrote:
> Hello All,
> According to ipa_check_consistency we have "LDAP Conflicts"
> (https://github.com/peterpakos/ipa_check_consistency).
>
> How do I find and resolve them?
https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html/administration_guide/managing_replication-solving_common_replication_conflicts

Enjoy,
Mark
>
> I've seen:
> Re: [Freeipa-devel] LDAP conflicts resolution API
> 
>
>
>   
>
>
> Re: [Freeipa-devel] LDAP conflicts resolution API
>
>   
>
> 
>
> But not sure if I am looking in the right place.
>
> Many thanks,
> James Harrison
>
>

-- 
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] Can't make replica with CA due to LDAP 'replication manager' user not found error

[Standa Laznicka]

On 05/04/2017 02:01 PM, Chris Dagdigian wrote:


Florence Blanc-Renaud wrote:

the issue looks similar to ticket 6766 [1]
Flo.

[1] https://pagure.io/freeipa/issue/6766



Thanks Flo, I agree that this looks like the issue I"m hitting in v4.4 
much appreciated!


I'm gonna be watching this closely, it's nerve wracking knowing that I 
can't use, update or create *any* replica servers at the moment ...


-Chris


You can, but you probably won't be able to install a CA replica on them 
(you have to leave out the --setup-ca option). In the meantime, you can 
create replicas without CA replication and when the Dogtag/DS guys solve 
the problem, you can run ipa-ca-install on those to setup CA replication 
there as well.
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

[Freeipa-users] Kerberos clients, service tickets, and client to KDC interaction

[Christopher Lamb]

Hi All

Is the following statement correct?

"If a kerberos client (e.g. a FreeIPA client) holds a service ticket to a
service principal in its credentials cache, it no longer needs to interact
with the KDC to access the service (assuming the ticket is still valid).
i.e. if a kerberos client is not caching service tickets, each interaction
with the service principal will require getting a new ticket from the KDC."

Are there logs on my FreeIPA-Server I can use to track ticket requests from
clients, and prove or disprove my statement above?

Cheers

Chris
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

[Freeipa-users] LDAP Conflicts

[James Harrison]

Hello All,According to ipa_check_consistency we have "LDAP Conflicts" 
(https://github.com/peterpakos/ipa_check_consistency).
How do I find and resolve them?
I've seen:Re: [Freeipa-devel] LDAP conflicts resolution API

  
|  
|   |  
Re: [Freeipa-devel] LDAP conflicts resolution API
   |  |

  |

 
But not sure if I am looking in the right place.
Many thanks,James Harrison
-- 
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] Getting a certificate for an alias

[Fraser Tweedale]

On Thu, May 04, 2017 at 05:36:26PM -0400, Steve Huston wrote:
> I'm trying to use certmonger to get an SSL certificate on a web host
> which has an alias.  I added the alias as a principal alias to the
> host record in FreeIPA, and I added the service as well with the
> actual hostname and the alias.  However every time certmonger contacts
> the CA, the request is rejected with "The service principal for
> subject alt name ... does not exist" (or earlier, another similar
> error which has now been lost to the scrollback).
> 
> hostname: coathook.astro.princeton.edu
> Principal alias: host/coathook.astro.princeton@astro.princeton.edu
> Principal alias: host/puppet.astro.princeton@astro.princeton.edu
> 
> Principal alias: HTTP/coathook.astro.princeton@astro.princeton.edu
> Principal alias: HTTP/puppet.astro.princeton@astro.princeton.edu
> Service: HTTP
> Host Name: coathook.astro.princeton.edu
> 
> ipa-getcert request -k /etc/pki/tls/private/puppetexplorer.key -f
> /etc/pki/tls/certs/puppetexplorer.crt -D puppet.astro.princeton.edu -N
> CN=coathook.astro.princeton.edu,O=ASTRO.PRINCETON.EDU -K
> HTTP/coathook.astro.princeton@astro.princeton.edu -C
> '/usr/sbin/apachectl graceful'
> 
> When I check with ipa-getcert list, I find:
> ca-error: Server at https://ipa.astro.princeton.edu/ipa/xml
> failed request, will retry: 4001 (RPC failed at server.  The service
> principal for subject alt name puppet.astro.princeton.edu in
> certificate request does not exist).
> 
> Other attempts used the CN of puppet, and the Kerberos principal of
> puppet as well, and they also failed but with the slightly different
> error (I believe it was that the host does not exist).
> 
> So how does one create a certificate for an alias on a host?
> 
Hi Steve,

The fix for this was released in FreeIPA 4.5.  See ticket
https://pagure.io/freeipa/issue/6295.

Thanks,
Fraser

-- 
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] Getting a certificate for an alias

[Steve Huston]

On Thu, May 4, 2017 at 9:15 PM, Fraser Tweedale  wrote:
> The fix for this was released in FreeIPA 4.5.  See ticket
> https://pagure.io/freeipa/issue/6295.
>

Excellent!  Any chance of that getting backported into the 4.4.x
series available on RHEL7?

-- 
Steve Huston - W2SRH - Unix Sysadmin, PICSciE/CSES & Astrophysical Sci
  Princeton University  |ICBM Address: 40.346344   -74.652242
345 Lewis Library   |"On my ship, the Rocinante, wheeling through
  Princeton, NJ   08544 | the galaxies; headed for the heart of Cygnus,
(267) 793-0852  | headlong into mystery."  -Rush, 'Cygnus X-1'

-- 
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] Getting a certificate for an alias

[Fraser Tweedale]

On Thu, May 04, 2017 at 10:30:39PM -0400, Steve Huston wrote:
> On Thu, May 4, 2017 at 9:15 PM, Fraser Tweedale  wrote:
> > The fix for this was released in FreeIPA 4.5.  See ticket
> > https://pagure.io/freeipa/issue/6295.
> >
> 
> Excellent!  Any chance of that getting backported into the 4.4.x
> series available on RHEL7?
> 
Anecdotally it's unlikely, but it cannot hurt to file a ticket /
support case and ask for it.

Cheers,
Fraser

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] LDAP Conflicts

[Ludwig Krispenz]

you can start here:

https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html/administration_guide/managing_replication-solving_common_replication_conflicts

you need first find out which conflict entries you have, which entries 
need to be preserved, and then can start to rename or delete the 
conflicts. there is no magic tool.


On 05/04/2017 04:20 PM, James Harrison wrote:

Hello All,
According to ipa_check_consistency we have "LDAP Conflicts" 
(https://github.com/peterpakos/ipa_check_consistency).


How do I find and resolve them?

I've seen:
Re: [Freeipa-devel] LDAP conflicts resolution API 







Re: [Freeipa-devel] LDAP conflicts resolution API





But not sure if I am looking in the right place.

Many thanks,
James Harrison




--
Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric 
Shander

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