[Freeipa-users] ipa-dnskeysyncd ipa : ERROR Login to LDAP server failed: {'desc': 'Invalid credentials'}

[Brian J. Murrell]

Hi,

After upgrading to EL 7.3 which included an upgrade of IPA from 4.2.0-
15.0.1.el7.centos.19 to 4.4.0-14.el7.centos I'm getting: 

22:01:00 ipa-dnskeysyncd ipa : INFO LDAP bind...
22:01:00 ipa-dnskeysyncd ipa : ERRORLogin to LDAP server failed: 
{'desc': 'Invalid credentials'}
22:01:00 ipa-dnskeysyncd Traceback (most recent call last):
22:01:00 ipa-dnskeysyncd File "/usr/libexec/ipa/ipa-dnskeysyncd", line 90, in 

22:01:00 ipa-dnskeysyncd ldap_connection.sasl_interactive_bind_s("", 
ipaldap.SASL_GSSAPI)
22:01:00 ipa-dnskeysyncd File 
"/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 850, in 
sasl_interactive_bind_s
22:01:00 ipa-dnskeysyncd res = 
self._apply_method_s(SimpleLDAPObject.sasl_interactive_bind_s,*args,**kwargs)
22:01:00 ipa-dnskeysyncd File 
"/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 818, in 
_apply_method_s
22:01:00 ipa-dnskeysyncd return func(self,*args,**kwargs)
22:01:00 ipa-dnskeysyncd File 
"/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 229, in 
sasl_interactive_bind_s
22:01:00 ipa-dnskeysyncd return 
self._ldap_call(self._l.sasl_interactive_bind_s,who,auth,RequestControlTuples(serverctrls),RequestControlTuples(clientctrls),sasl_flags)
22:01:00 ipa-dnskeysyncd File 
"/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 99, in _ldap_call
22:01:00 ipa-dnskeysyncd result = func(*args,**kwargs)
22:01:00 ipa-dnskeysyncd INVALID_CREDENTIALS: {'desc': 'Invalid credentials'}
22:01:01 systemd ipa-dnskeysyncd.service: main process exited, code=exited, 
status=1/FAILURE
22:01:01 systemd Unit ipa-dnskeysyncd.service entered failed state.
22:01:01 systemd ipa-dnskeysyncd.service failed.

But I also had to fall back to simple authentication of bind with

arg "auth_method simple";
arg "bind_dn uid=admin,cn=users,cn=accounts,dc=example.com";
arg "password my_password";

in /etc/named.conf due to:

21:12:19 LDAP error: Invalid credentials: bind to LDAP server failed

trying to start bind via systemctl start ipa.

Seems like something's gotten fouled up during that upgrade.

Any ideas?

Cheers,
b.


signature.asc
Description: This is a digitally signed message part
-- 
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] Replica issue / Certificate Authority

[Christopher Young]

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

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 applied to each system, I noticed that the
> results of 'ipa-server-upgrade' were quite different.  The 'ipa02'
> system went through without errors (this was also the system I used to
> reinitialize the other when I had a replication issue recently).
>
>
>
> On 'ipa01', I have following at the end of the 'ipaupgrade.log' file:
> --
> 2016-12-14T18:09:26Z ERROR IPA server upgrade failed: Inspect
> /var/log/ipaupgrade.log and run command ipa-server-upgrade manually.
> 2016-12-14T18:09:26Z DEBUG   File
> "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 171,
> in execute
> return_value = self.run()
>   File 
> "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_server_upgrade.py",
> line 46, in run
> server.upgrade()
>   File "/usr/lib/python2.7/site-packages/ipaserver/install/server/upgrade.py",
> line 1863, in upgrade
> upgrade_configuration()
>   File 

Re: [Freeipa-users] FreeIPA 4.2.0: An error has occurred (IPA Error 4301: CertificateOperationError)

[Christopher Young]

I have a similar issue (see my recent list post), and I was wondering
if this was ever fixed?  CA appears to work one system
(master/replica) but not the other.

On Mon, Jun 13, 2016 at 4:41 AM, Petr Vobornik  wrote:
> On 06/12/2016 07:05 PM, dan.finkelst...@high5games.com wrote:
>> The restore I was referring to was a red herring; we ended up wiping the 
>> server
>> and saving ipa-backup files, which was the only way we could successfully
>> reconfigure/reinitialize IPA on the host.
>>
>
> As Rob wrote, please check PKI logs. The most important ones here are:
>
> /var/log/pki/pki-tomcat/ca/selftests.log
> /var/log/pki/pki-tomcat/ca/debug
>
> Debug log usually has additional info for possible cause logged in
> selftest log.
>
>
>> *From: *Rob Crittenden 
>> *Date: *Friday, June 10, 2016 at 17:17
>> *To: *Daniel Finkestein ,
>> "freeipa-users@redhat.com" 
>> *Subject: *Re: [Freeipa-users] FreeIPA 4.2.0: An error has occurred (IPA 
>> Error
>> 4301: CertificateOperationError)
>>
>> dan.finkelst...@high5games.com  wrote:
>>
>> And, from the 'ipactl -d --ignore-service-failures restart' we get this:
>>
>> ipa: DEBUG: stderr=
>>
>> ipa: DEBUG: wait_for_open_ports: localhost [8080, 8443] timeout 300
>>
>> ipa: DEBUG: Waiting until the CA is running
>>
>> ipa: DEBUG: Starting external process
>>
>> ipa: DEBUG: args='/usr/bin/wget' '-S' '-O' '-' '--timeout=30'
>>
>> '--no-check-certificate'
>>
>> 'https://ipa.example.com:8443/ca/admin/ca/getStatus'
>>
>> ipa: DEBUG: Process finished, return code=4
>>
>> ipa: DEBUG: stdout=
>>
>> ipa: DEBUG: stderr=--2016-06-10 15:29:38--
>>
>> https://ipa.example.com:8443/ca/admin/ca/getStatus
>>
>> Resolving ipa.example.com (ipa.example.com)... 10.55.10.31
>>
>> Connecting to ipa.example.com (ipa.example.com)|10.55.10.31|:8443...
>>
>> connected.
>>
>> Unable to establish SSL connection.
>>
>> ipa: DEBUG: The CA status is: check interrupted due to error: Command
>>
>> ''/usr/bin/wget' '-S' '-O' '-' '--timeout=30' '--no-check-certificate'
>>
>> 'https://ipa.example.com:8443/ca/admin/ca/getStatus'' returned non-zero
>>
>> exit status 4
>>
>> 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://ipa.example.com:8443/ca/admin/ca/getStatus'
>>
>> ipa: DEBUG: Process finished, return code=4
>>
>> ipa: DEBUG: stdout=
>>
>> ipa: DEBUG: stderr=--2016-06-10 15:29:43--
>>
>> https://ipa.example.com:8443/ca/admin/ca/getStatus
>>
>> Resolving ipa.example.com (ipa.example.com)... 10.55.10.31
>>
>> Connecting to ipa.example.com (ipa.example.com)|10.55.10.31|:8443...
>>
>> connected.
>>
>> Unable to establish SSL connection.
>>
>> ipa: DEBUG: The CA status is: check interrupted due to error: Command
>>
>> ''/usr/bin/wget' '-S' '-O' '-' '--timeout=30' '--no-check-certificate'
>>
>> 'https://ipa.example.com:8443/ca/admin/ca/getStatus'' returned non-zero
>>
>> exit status 4
>>
>> 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://ipa.example.com:8443/ca/admin/ca/getStatus'
>>
>> Which leads me to believe that tomcat doesn't have the right 
>> certificate(s).
>>
>> I don't think that's the problem. I'd check the pki logs to see if it
>>
>> started and if not, why. Note that it is quite possible for tomcat to
>>
>> start and the CA to fail because tomcat is just a container.
>>
>> In a previous e-mail you said something about a restore, what was that?
>>
>> rob
>>
>> 
>>
>> *Daniel Alex Finkelstein*| Lead Dev Ops Engineer
>>
>> _dan.finkelst...@h5g.com 
>> _| 
>> 212.604.3447
>>
>> One World Trade Center, New York, NY 10007
>>
>> www.high5games.com 
>>
>> Play High 5 Casino  and Shake
>>
>> the Sky 
>>
>> Follow us on: Facebook , Twitter
>>
>> , YouTube
>>
>> , Linkedin
>>
>> 
>>
>> //
>>
>> /This message and any attachments may contain confidential or privileged
>>
>> information and are only for the use of the intended recipient of this
>>
>> message. If you are not the intended recipient, please notify the sender
>>
>> by return email, and delete or 

[Freeipa-users] Replica issue / Certificate Authority

[Christopher Young]

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 applied to each system, I noticed that the
results of 'ipa-server-upgrade' were quite different.  The 'ipa02'
system went through without errors (this was also the system I used to
reinitialize the other when I had a replication issue recently).



On 'ipa01', I have following at the end of the 'ipaupgrade.log' file:
--
2016-12-14T18:09:26Z ERROR IPA server upgrade failed: Inspect
/var/log/ipaupgrade.log and run command ipa-server-upgrade manually.
2016-12-14T18:09:26Z DEBUG   File
"/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 171,
in execute
return_value = self.run()
  File 
"/usr/lib/python2.7/site-packages/ipaserver/install/ipa_server_upgrade.py",
line 46, in run
server.upgrade()
  File "/usr/lib/python2.7/site-packages/ipaserver/install/server/upgrade.py",
line 1863, in upgrade
upgrade_configuration()
  File "/usr/lib/python2.7/site-packages/ipaserver/install/server/upgrade.py",
line 1785, in upgrade_configuration
ca_enable_ldap_profile_subsystem(ca)
  File "/usr/lib/python2.7/site-packages/ipaserver/install/server/upgrade.py",
line 336, in ca_enable_ldap_profile_subsystem
cainstance.migrate_profiles_to_ldap()
  File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py",
line 1984, in migrate_profiles_to_ldap
_create_dogtag_profile(profile_id, profile_data, overwrite=False)
  File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py",
line 1990, in _create_dogtag_profile
with api.Backend.ra_certprofile as profile_api:
  File "/usr/lib/python2.7/site-packages/ipaserver/plugins/dogtag.py",
line 2060, in __enter__
raise errors.RemoteRetrieveError(reason=_('Failed to authenticate
to CA REST API'))

2016-12-14T18:09:26Z DEBUG The ipa-server-upgrade command failed,
exception: RemoteRetrieveError: Failed to authenticate to CA REST API
2016-12-14T18:09:26Z ERROR Unexpected error - see
/var/log/ipaupgrade.log for details:
RemoteRetrieveError: Failed to authenticate to CA REST API
2016-12-14T18:09:26Z ERROR The ipa-server-upgrade command failed. See
/var/log/ipaupgrade.log for more information
--


In addition, when I go to the IPA web interface on the 'ipa01' system,
I get the following when I try to view any of the certificates:
--
IPA Error 4301: CertificateOperationError

Certificate operation cannot be completed: EXCEPTION (Invalid Credential.)
--


I was wondering if there was a method for taking all the CA
details/tree/what have you from my 'ipa02' system and using it to
repopulate the 'ipa01'.   Since everything else seems to be working
correctly after a reinitialize on 'ipa01', I thought this would be the
safest way, but I'm opening any solutions as I need to get this fixed
ASAP.

Please let me know any additional details that may help OR if there is
a procedure that I could use to quickly and easily recreate 'ipa01'
WITH the certificate authority properly working on both.  I may need
some educate there.


Thanks!

-- 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] Add text to web login page

[Mike Waite]

I need to add a login banner to the login page for freeIPA, is there a
setting that I could easily change for this?

Thanks,
--
Mike Waite


-- 
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] FYI incorrect configuration when using ipa-client-automount

[Rob Verduijn]

Hello,

I've was being bugged by a non functional automounter.

So I tried a fresh centos7.3 install (minimal) with only the additional
package ipa-client.

I did the installation and update to latest patch level and reboot.

Then ran ipa-client-install --enable-dns-updates
Did the yes/admin account/auth
And I had a fully functional freeipa-domain-client.

Then I ran ipa-client-automount
yes again.
and no functional automounter.

It appeared that the 'ipa-client-automount' tool did not adjust the
/etc/nsswitch.conf file properly.

In one occasion it replaced 'automount: files nisplus' with 'automount:
files'
in another it did not change it at all.

After editing /etc/nsswitch.conf and setting it to 'automount: files sss'
all was working as expected.

Because there is not mention about centos on
https://fedorahosted.org/freeipa/
and I'm used to seeing closed not supported on the redhat bugzilla when the
word centos is mentioned
I've posterd it in the centos buglist :
https://bugs.centos.org/view.php?id=12415

Cheers
Rob Verduijn
-- 
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] Failed ipa-client-install with IPA Replica

[Florence Blanc-Renaud]

On 12/15/2016 08:01 PM, beeth beeth wrote:

Hi Flo,

That's a good point! I checked the dirsrv certificate and confirmed
valid(good until later next year).
Since I had no problem to enroll another new IPA client(RHEL7 box
instead of RHEL6) to such replica server, I thought it might not be a
server end issue. However, when I tried to restart the DIRSRV service on
the replica server, I found these messages in the log
file /var/log/dirsrv/slapd-IPA-EXAMPLE-COM/errors:

[15/Dec/2016:13:38:15.891301246 -0500] 389-Directory/1.3.5.10
 B2016.257.1817 starting up
[15/Dec/2016:13:38:15.911777373 -0500] default_mr_indexer_create:
warning - plugin [caseIgnoreIA5Match] does not handle caseExactIA5Match
[15/Dec/2016:13:38:15.926320306 -0500] WARNING: changelog: entry cache
size 2097152 B is less than db size 5488640 B; We recommend to increase
the entry cache size nsslapd-cachememsize.
[15/Dec/2016:13:38:16.132155534 -0500] schema-compat-plugin - scheduled
schema-compat-plugin tree scan in about 5 seconds after the server startup!
[15/Dec/2016:13:38:16.167896279 -0500] NSACLPlugin - The ACL target
cn=dns,dc=ipa,dc=example,dc=com does not exist
[15/Dec/2016:13:38:16.173317345 -0500] NSACLPlugin - The ACL target
cn=dns,dc=ipa,dc=example,dc=com does not exist
[15/Dec/2016:13:38:16.178354342 -0500] NSACLPlugin - The ACL target
cn=keys,cn=sec,cn=dns,dc=ipa,dc=example,dc=com does not exist
[15/Dec/2016:13:38:16.183579322 -0500] NSACLPlugin - The ACL target
cn=dns,dc=ipa,dc=example,dc=com does not exist
[15/Dec/2016:13:38:16.188786976 -0500] NSACLPlugin - The ACL target
cn=dns,dc=ipa,dc=example,dc=com does not exist
[15/Dec/2016:13:38:16.193275650 -0500] NSACLPlugin - The ACL target
cn=groups,cn=compat,dc=ipa,dc=example,dc=com does not exist
[15/Dec/2016:13:38:16.197580407 -0500] NSACLPlugin - The ACL target
cn=computers,cn=compat,dc=ipa,dc=example,dc=com does not exist
[15/Dec/2016:13:38:16.201863256 -0500] NSACLPlugin - The ACL target
cn=ng,cn=compat,dc=ipa,dc=example,dc=com does not exist
[15/Dec/2016:13:38:16.206318629 -0500] NSACLPlugin - The ACL target
ou=sudoers,dc=ipa,dc=example,dc=com does not exist
[15/Dec/2016:13:38:16.211559100 -0500] NSACLPlugin - The ACL target
cn=users,cn=compat,dc=ipa,dc=example,dc=com does not exist
[15/Dec/2016:13:38:16.216146819 -0500] NSACLPlugin - The ACL target
cn=vaults,cn=kra,dc=ipa,dc=example,dc=com does not exist
[15/Dec/2016:13:38:16.220786596 -0500] NSACLPlugin - The ACL target
cn=vaults,cn=kra,dc=ipa,dc=example,dc=com does not exist
[15/Dec/2016:13:38:16.225594942 -0500] NSACLPlugin - The ACL target
cn=vaults,cn=kra,dc=ipa,dc=example,dc=com does not exist
[15/Dec/2016:13:38:16.229986749 -0500] NSACLPlugin - The ACL target
cn=vaults,cn=kra,dc=ipa,dc=example,dc=com does not exist
[15/Dec/2016:13:38:16.234518367 -0500] NSACLPlugin - The ACL target
cn=vaults,cn=kra,dc=ipa,dc=example,dc=com does not exist
[15/Dec/2016:13:38:16.238763121 -0500] NSACLPlugin - The ACL target
cn=vaults,cn=kra,dc=ipa,dc=example,dc=com does not exist
[15/Dec/2016:13:38:16.243031116 -0500] NSACLPlugin - The ACL target
cn=vaults,cn=kra,dc=ipa,dc=example,dc=com does not exist
[15/Dec/2016:13:38:16.247507984 -0500] NSACLPlugin - The ACL target
cn=vaults,cn=kra,dc=ipa,dc=example,dc=com does not exist
[15/Dec/2016:13:38:16.252327210 -0500] NSACLPlugin - The ACL target
cn=vaults,cn=kra,dc=ipa,dc=example,dc=com does not exist
[15/Dec/2016:13:38:16.259046910 -0500] NSACLPlugin - The ACL target
cn=vaults,cn=kra,dc=ipa,dc=example,dc=com does not exist
[15/Dec/2016:13:38:16.263856581 -0500] NSACLPlugin - The ACL target
cn=vaults,cn=kra,dc=ipa,dc=example,dc=com does not exist
[15/Dec/2016:13:38:16.269301704 -0500] NSACLPlugin - The ACL target
cn=ad,cn=etc,dc=ipa,dc=example,dc=com does not exist
[15/Dec/2016:13:38:16.283511408 -0500] NSACLPlugin - The ACL target
cn=casigningcert
cert-pki-ca,cn=ca_renewal,cn=ipa,cn=etc,dc=ipa,dc=example,dc=com does
not exist
[15/Dec/2016:13:38:16.287853825 -0500] NSACLPlugin - The ACL target
cn=casigningcert
cert-pki-ca,cn=ca_renewal,cn=ipa,cn=etc,dc=ipa,dc=example,dc=com does
not exist
[15/Dec/2016:13:38:16.395872649 -0500] NSACLPlugin - The ACL target
cn=automember rebuild membership,cn=tasks,cn=config does not exist
[15/Dec/2016:13:38:16.405404114 -0500] Skipping CoS Definition
cn=Password Policy,cn=accounts,dc=ipa,dc=example,dc=com--no CoS
Templates found, which should be added before the CoS Definition.
[15/Dec/2016:13:38:16.463117873 -0500] set_krb5_creds - Could not get
initial credentials for principal
[ldap/ipaprd2.example@ipa.example.com
] in keytab
[FILE:/etc/dirsrv/ds.keytab]: -1765328324 (Generic error (see e-text))
[15/Dec/2016:13:38:16.471256279 -0500] schema-compat-plugin -
schema-compat-plugin tree scan will start in about 5 seconds!
[15/Dec/2016:13:38:16.479213976 -0500] slapd started.  Listening on All
Interfaces port 389 for LDAP requests
[15/Dec/2016:13:38:16.483683353 -0500] Listening on

[Freeipa-users] Announcing bind-dyndb-ldap version 11.0

[Tomas Krizek]

The FreeIPA team is proud to announce bind-dyndb-ldap version 11.0.

It can be downloaded fromhttps://fedorahosted.org/released/bind-dyndb-ldap/

The new version has also been built for Fedora Rawhide.


Latest news:

11.0

[1] The plugin was ported to BIND 9.11. Minimal BIND version is now 9.11.0rc1.
https://fedorahosted.org/bind-dyndb-ldap/ticket/161

[2] Configuration format in named.conf is different
and incompatible with all previous versions. Please see README.md.

[3] Obsolete plugin options were removed:
cache_ttl, psearch, serial_autoincrement, zone_refresh.


== Upgrading ==
A server can be upgraded by installing updated RPM. If your named.conf has
configuration for dyndb, you need to manually update it to reflect the new
configuration format. Please see README.md for more information. BIND has to
be manually restarted afterwards.


== Limited compatibility with BIND 9 ==
bind-dyndb-ldap version 11.0 is only compatible with BIND 9.11 and newer.


== Known Issues ==
There are the following issues in Fedora Rawhide:
- 1403352: New FreeIPA installations generate old and incompatible configuration
  in named.conf.
- 1404409: Using GSSAPI authentication for 389-ds results in an error, simple
  bind is not affected.
- named-pkcs11 does not start with dyndb configured. named is not affected.
We are currently working on resolving these issues.


== Feedback ==
Please provide comments, report bugs, and send any other feedback via the
freeipa-users mailing list:
http://www.redhat.com/mailman/listinfo/freeipa-users

--
Tomas Krizek

--
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 after centos 7.3 upgrade

[Rob Verduijn]

2016-12-15 13:47 GMT+01:00 Petr Vobornik :

> On 12/12/2016 08:53 PM, Rob Verduijn wrote:
> > Hello,
> >
> > I've recently upgraded to centos 7.3.
> > Didn't intend to so soon but should have checked the anounce lists before
> > launching my ansible update playbook.
> >
> > Most of my servers came through, and mostly also the ipa server.
> > There were duplicate rpms and a failed rpm upgrade.
> > After some yum magic the rpm duplicates where gone and all the updates
> installed.
> >
> > Manually running ipa-server-upgrade also seems to finish properly.
> >
> > However
> > ipactl start keeps failing on the ntpd service.
> > Not a big surprise since its running chronyd.
> >
> > I now start the ipa server with 'ipactl start --ignore-service-failure'
> >
> > Is there a way to explain the script that it should check for chronyd
> instead of
> > ntpd ?
> >
> > I also see this a lot in the logs:
> > dns_rdatatype_fromtext() failed for attribute
> > 'idnsTemplateAttribute;cnamerecord': unknown class/type
> >
> > Is that a serious error ?
> >
> > Rob Verduijn
> >
>
> This looks like 7.3 update incorrectly added NTP service to IPA server
> services (which is displayed as NTP role in `ipa server-show $server`).
>
> A workaround might be to disable the service or remove the service
> entry. Disabling is IMHO safer.  IPA CLI tools don't allow
> enabling/disabling of services so it must be done by LDAP mod.
>
> It can be done by removing  'enabledService' config value from server's
> service entry, e.g.:
>
> dn: cn=NTP,cn=$SERVER_FQDN,cn=masters,cn=ipa,cn=etc,$SUFFIX
> changetype: modify
> delete: ipaConfigString
> ipaConfigString: enabledService
> -
>
> Where $SERVER_FQDN is e.g. ipa.example.com and $SUFFIX is e.g.
> dc=example,dc=com
>
>
> Rob, have you originally installed the replica with NTPD and then later
> switched manually to chrony?
>
> --
> Petr Vobornik
>

Hello,

I can't remember if I installed and configured freeipa and then switched to
chronyd or the other way around.

I had my ntpd/ntpdate services masked because I got tired of stopping and
disabling them all the time.
It seems ipactl can't deal with that.

Currently I unmasked the services and enabled them (disabling chronyd) so
that the server boots properly.

I will try your ldiff to see if I can switch back, since I do not use my
ipa server as a time source for clients.

I'll let you know the results.

Rob Verduijn
-- 
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 realm for different domain

[Brian Candler]

On 16/12/2016 10:19, Alexander Bokovoy wrote:
I want to allow users in the AD.EXAMPLE.COM realm to login to 
machines in the IPA.EXAMPLE.COM realm.


Will this still work when the machines are in different DNS domains? 

Yes, it will. Here is the catch: you need to make sure these different
DNS domains all mentioned in 'ipa realmdomains-show' and if not, they
should be added by use of 'ipa realmdomains-mod'. None of these domains
must overlap with Active Directory domains, of course. 


Fantastic answer. Thank you so much for taking the time to explain this.

Regards,

Brian.

-- 
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 realm for different domain

[Alexander Bokovoy]

On pe, 16 joulu 2016, Brian Candler wrote:

On 16/12/2016 08:21, Alexander Bokovoy wrote:


So you can have IPA masters with FQDNs in totally different DNS domains
than dictated by their Kerberos realm and --domain options.


That I understand - not only can the IPA masters have FQDNs in 
different DNS domains, but indeed the member machines of that realm as 
well.


What was unclear to me was whether "ipa-server-install --domain xxx" 
affects the content of the database being built (and therefore 
replicated later to the slaves), or is just something local to the 
host itself.


In the manpage for "ipa-client-install" it's much clearer: in that 
case, it says that --domain is the starting domain for LDAP server 
auto-discovery.


To clarify, there are several DNS auto-discovery mechanisms. Two of 
them are described in the MIT docs at

https://web.mit.edu/kerberos/krb5-1.6/krb5-1.6.3/doc/krb5-admin.html#Using-DNS

(1) Map hostname aaa.bbb.ccc to realm xxx.yyy.zzz

Look for TXT records for _kerberos.aaa.bbb.ccc, _kerberos.bbb.ccc, 
_kerberos.ccc. The TXT record gives the realm that this host belongs 
to.


(2) Realm xxx.yyy.zzz to Kerberos servers for that realm

Given realm xxx.yyy.zzz, look for in the DNS for SRV records for
_kerberos._udp.xxx.yyy.zzz
_kerberos-master._udp.xxx.yyy.zzz
_kpasswd._udp.xxx.yyy.zzz

This is all very clear.

Now, the manpage for ipa-client-install describes another one, which 
is where I get a bit fuzzy:


(3)

  DNS Autodiscovery
  Client installer by default tries to search for 
_ldap._tcp.DOMAIN  DNS SRV  records for all domains that are parent to

its hostname.  For example, if a client machine has a hostname
'client1.lab.example.com',  the installer will try to retrieve
an IPA server hostname from _ldap._tcp.lab.example.com,
_ldap._tcp.example.com and _ldap._tcp.com DNS  SRV  records,
respectively. The discovered domain is then used to configure client
components (e.g. SSSD and Kerberos 5 configuration) on
the machine.

What it doesn't actually say (but I believe must be true) is that what 
it calls the "discovered domain" is in fact the *realm* to use.  If 
so, effectively this is algorithm (2) in reverse: instead of using it 
for realm to SRV mapping, you hunt for a domain which contains the 
right SRV records and use this to infer your realm.


Is that right?

In case of IPA client you need to deal with both Kerberos realm and
application-level LDAP servers. The latter aren't related to Kerberos
realm themselves. However, authentication to them is based on GSSAPI and
thus Kerberos. So discovery of the LDAP servers is done via SRV records
according to https://tools.ietf.org/html/draft-ietf-ldapext-locate-08
and RFC2782 but Kerberos configuration is done based on the
corresponding DNS SRV records too (_ldap versus _kerberos for two
different purposes).

It became customary when Active Directory was introduced in 2000, that
when both _ldap..domain and _kerberos..domain DNS
SRV records exist, they are assumed to be explaining the services from
the same Kerberos realm. On MIT Kerberos side use of DNS TXT record
allows you to easily discover the actual name of the realm too. On
Active Directory side it is not the case but there realm name is equal
to the DNS domain name for the AD domains and additional DNS domains are
actually discovered through completely different means -- by using
netr_DsRGetForestTrustInformation function over LSA pipe.

(Is this a mechanism modelled on Active Directory? Otherwise, I would 
have thought you could use MIT algorithm (1) to discover your realm)

https://tools.ietf.org/html/draft-ietf-ldapext-locate-08 was driven by
Microsoft and since early 2000s was implemented in many LDAP libraries.
Needless to say, OpenLDAP utilities supports DNS SRV records discovery too,
see -H option in ldapsearch manual page for example.


After all, these are *flexibility* options. They are not supposed to
make sense in all combinations. Where they aren't making sense, you are
allowed to shoot yourself in your feet if you know what you are doing.


Absolutely, and I don't want to get this wrong and have to start again :-)

OK, I have a final question on the planning of realms and DNS.

As we've already said, in an IPA-only installation, the machines which 
are members of the realms can happily have hostnames which are 
unrelated to the realm name: e.g.


IPA.EXAMPLE.COM
| | |
machines .foo.com
machines .bar.com

A user in IPA.EXAMPLE.COM can login to host .foo.com, either 
because their krb5.conf has a static domain->realm mapping, or there's 
a DNS entry: _kerberos.foo.com TXT "IPA.EXAMPLE.COM"


However, suppose I plan to end up with a trust to an Active Directory 
/ Samba4 realm:


AD.EXAMPLE.COM <--trust--> IPA.EXAMPLE.COM
   | | |  | | |
   usersmachines

I want to allow users in the AD.EXAMPLE.COM realm to login to machines 
in the IPA.EXAMPLE.COM realm.


Will this still work when the machines are in 

Re: [Freeipa-users] Kerberos realm for different domain

[Brian Candler]

On 16/12/2016 08:21, Alexander Bokovoy wrote:


So you can have IPA masters with FQDNs in totally different DNS domains
than dictated by their Kerberos realm and --domain options.


That I understand - not only can the IPA masters have FQDNs in different 
DNS domains, but indeed the member machines of that realm as well.


What was unclear to me was whether "ipa-server-install --domain xxx" 
affects the content of the database being built (and therefore 
replicated later to the slaves), or is just something local to the host 
itself.


In the manpage for "ipa-client-install" it's much clearer: in that case, 
it says that --domain is the starting domain for LDAP server auto-discovery.


To clarify, there are several DNS auto-discovery mechanisms. Two of them 
are described in the MIT docs at

https://web.mit.edu/kerberos/krb5-1.6/krb5-1.6.3/doc/krb5-admin.html#Using-DNS

(1) Map hostname aaa.bbb.ccc to realm xxx.yyy.zzz

Look for TXT records for _kerberos.aaa.bbb.ccc, _kerberos.bbb.ccc, 
_kerberos.ccc. The TXT record gives the realm that this host belongs to.


(2) Realm xxx.yyy.zzz to Kerberos servers for that realm

Given realm xxx.yyy.zzz, look for in the DNS for SRV records for
_kerberos._udp.xxx.yyy.zzz
_kerberos-master._udp.xxx.yyy.zzz
_kpasswd._udp.xxx.yyy.zzz

This is all very clear.

Now, the manpage for ipa-client-install describes another one, which is 
where I get a bit fuzzy:


(3)

   DNS Autodiscovery
   Client installer by default tries to search for 
_ldap._tcp.DOMAIN  DNS
   SRV  records for all domains that are parent to its hostname. 
For exam-
   ple, if a client machine has a hostname 
'client1.lab.example.com',  the
   installer   will   try   to   retrieve  an  IPA  server 
hostname  from
   _ldap._tcp.lab.example.com, _ldap._tcp.example.com  and 
_ldap._tcp.com
   DNS  SRV  records,  respectively. The discovered domain is then 
used to
   configure client components (e.g. SSSD and Kerberos 5 
configuration) on

   the machine.

What it doesn't actually say (but I believe must be true) is that what 
it calls the "discovered domain" is in fact the *realm* to use.  If so, 
effectively this is algorithm (2) in reverse: instead of using it for 
realm to SRV mapping, you hunt for a domain which contains the right SRV 
records and use this to infer your realm.


Is that right?

(Is this a mechanism modelled on Active Directory? Otherwise, I would 
have thought you could use MIT algorithm (1) to discover your realm)




After all, these are *flexibility* options. They are not supposed to
make sense in all combinations. Where they aren't making sense, you are
allowed to shoot yourself in your feet if you know what you are doing.


Absolutely, and I don't want to get this wrong and have to start again :-)

OK, I have a final question on the planning of realms and DNS.

As we've already said, in an IPA-only installation, the machines which 
are members of the realms can happily have hostnames which are unrelated 
to the realm name: e.g.


 IPA.EXAMPLE.COM
 | | |
machines .foo.com
machines .bar.com

A user in IPA.EXAMPLE.COM can login to host .foo.com, either 
because their krb5.conf has a static domain->realm mapping, or there's a 
DNS entry: _kerberos.foo.com TXT "IPA.EXAMPLE.COM"


However, suppose I plan to end up with a trust to an Active Directory / 
Samba4 realm:


AD.EXAMPLE.COM <--trust--> IPA.EXAMPLE.COM
| | |  | | |
usersmachines

I want to allow users in the AD.EXAMPLE.COM realm to login to machines 
in the IPA.EXAMPLE.COM realm.


Will this still work when the machines are in different DNS domains? Or 
at this point, am I forced to give all the machines hostnames of the 
form .ipa.example.com ?


If the latter is true, it would be wise for me to start naming my hosts 
.ipa.example.com in the first place.


Thanks,

Brian.

--
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 realm for different domain

[Alexander Bokovoy]

On to, 15 joulu 2016, Brian Candler wrote:
On Sun, Dec 11, 2016 at 11:31 PM, David Kupka > wrote:



   yes you can do it. DNS domain and Kerberos realm are two different
   things. It's common and AFAIK recommended to capitalize DNS domain
   to get the realm but it's not required.
   If you really want to have them different make sure:
   a) anotherdomain.com  is under your
   control,
   b) you don't already have other Kerberos instance (FreeIPA, MIT
   KRB5, MS AD, ...) with ANOTHERDOMAIN.COM
    realm deployed.

   With FreeIPA you can run
   # ipa-server-install --domain example.com
    --realm ANOTHERDOMAIN.COM
   

   But before you do, why do you want to have the realm different
   from the domain?




Question: what "domain" does the --domain option to ipa-server-install 
actually refer to?


The man page just says " Your DNS domain name". But what does it 
actually alter?


1. the DNS domain which holds the kerberos realm location information? 
I don't think so; I think if you are searching for realm FOO.COM 
you'll always look in the DNS under "foo.com", that's a fixed 
relationship.


2. the DNS name of the IPA server itself? But if set up correctly, it 
already has an FQDN (as reported by "hostname -f"). And if you give 
the "--hostname" option, that's a FQDN not a bare hostname.


3. the DNS zone which IPA is authoritative for? But you can run IPA 
without integrated DNS.


4. the LDAP base DN? I guess that could be it: e.g. "--domain foo.com" 
puts everything under tree "dc=foo,dc=com"?


5. something else?

It is a combination of some of the above.

LDAP base DN is generated based on the realm name. DNS domain specified
in --domain option is considered a DNS domain we are authoritative for
in the case we install with integrated DNS server. Kerberos realm name
effectively forces use of the DNS domain equal to the realm name as your
primary DNS domain (forest root domain in terms of Active Directory),
but given that we could remap DNS and realm relationship with krb5.conf,
we are at a bit more flexibility than Active Directory design allows
here.

So you can have IPA masters with FQDNs in totally different DNS domains
than dictated by their Kerberos realm and --domain options. In such
situation you would need to make sure there are additional hints for the
IPA clients to properly find these IPA masters, but nothing dramatically
serious. You can have Kerberos realm and --domain options to point to
different DNS domains too, though we would not recommend that in a
longer term given you'd still need to own DNS domain named as your
Kerberos realm to have autodiscovery working.

After all, these are *flexibility* options. They are not supposed to
make sense in all combinations. Where they aren't making sense, you are
allowed to shoot yourself in your feet if you know what you are doing.

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