[Freeipa-users] Re: missing attribute "krbPrincipalName" required by object class "ipaKrbPrincipal"

2022-01-28 Thread Brian J. Murrell via FreeIPA-users
On Fri, 2022-01-28 at 16:02 +0100, Florence Blanc-Renaud wrote:
> Hi,
> you can do
> (on another server)
> $ ipa server-del --force server.example.com

# ipa server-del --force server.example.com
Removing server.example.com from replication topology, please wait...
ipa: WARNING: Forcing removal of server.example.com
ipa: WARNING: Failed to cleanup server.example.com DNS entries: no matching 
entry found
ipa: WARNING: You may need to manually remove them from the tree
ipa: WARNING: Server has already been deleted
---
Deleted IPA server "server.example.com"
---

> This should clean up all references to server.example.com

Hopefully it did. :-)

> (on server.example.com)
> $ ipa-client-install --uninstall -U
> $ kdestroy -A
> $ ipa-client-install ...
> $ kinit admin
> $ ipa-replica-install ...

This has now gotten as far as:


# ipa-replica-install --setup-ca --ip-address 10.75.22.247 --setup-dns 
--no-forwarders
...
Configuring certificate server (pki-tomcatd). Estimated time: 3 minutes
  [1/29]: creating certificate server db
  [2/29]: setting up initial replication
Starting replication, please wait until this has completed.
Update in progress, 12 seconds elapsed
Update succeeded

  [3/29]: creating ACIs for admin
  [4/29]: creating installation admin user
  [5/29]: configuring certificate server instance
Failed to configure CA instance
See the installation logs and the following files/directories for more 
information:
  /var/log/pki/pki-tomcat
  [error] RuntimeError: CA configuration failed.
Your system may be partly configured.
Run /usr/sbin/ipa-server-install --uninstall to clean up.

CA configuration failed.
The ipa-replica-install command failed. See /var/log/ipareplica-install.log for 
more information

At the end of /var/log/ipareplica-install.log is the error:

com.netscape.certsrv.base.ConflictingOperationException: Entry already exists.
at 
com.netscape.certsrv.ldap.LDAPExceptionConverter.toPKIException(LDAPExceptionConverter.java:45)
at com.netscape.cmscore.usrgrp.UGSubsystem.addUser(UGSubsystem.java:720)
at 
org.dogtagpki.server.cli.SubsystemUserAddCLI.execute(SubsystemUserAddCLI.java:180)
at org.dogtagpki.cli.CommandCLI.execute(CommandCLI.java:58)
at org.dogtagpki.cli.CLI.execute(CLI.java:357)
at org.dogtagpki.cli.CLI.execute(CLI.java:357)
at org.dogtagpki.cli.CLI.execute(CLI.java:357)
at org.dogtagpki.server.cli.PKIServerCLI.execute(PKIServerCLI.java:93)
at org.dogtagpki.server.cli.PKIServerCLI.main(PKIServerCLI.java:123)
Caused by: netscape.ldap.LDAPException: error result (68); Already exists
at netscape.ldap.LDAPConnection.checkMsg(Unknown Source)
at netscape.ldap.LDAPConnection.add(Unknown Source)
at netscape.ldap.LDAPConnection.add(Unknown Source)
at netscape.ldap.LDAPConnection.add(Unknown Source)
at com.netscape.cmscore.usrgrp.UGSubsystem.addUser(UGSubsystem.java:717)
... 7 more
CalledProcessError: Command '['/usr/sbin/runuser', '-u', 'pkiuser', '--', 
'/usr/lib/jvm/jre-1.8.0-openjdk/bin/java', '-classpath', 
'/usr/share/tomcat/bin/tomcat-juli.jar:/usr/share/java/tomcat-servlet-api.jar:/usr/share/pki/ca/webapps/ca/WEB-INF/lib/*:/var/lib/pki/pki-tomcat/common/lib/*:/usr/share/pki/lib/*',
 
'-Djavax.sql.DataSource.Factory=org.apache.commons.dbcp.BasicDataSourceFactory',
 '-Dcatalina.base=/var/lib/pki/pki-tomcat', 
'-Dcatalina.home=/usr/share/tomcat', '-Djava.endorsed.dirs=', 
'-Djava.io.tmpdir=/var/lib/pki/pki-tomcat/temp', 
'-Djava.util.logging.config.file=/etc/pki/pki-tomcat/logging.properties', 
'-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager', 
'-Dcom.redhat.fips=false', 'org.dogtagpki.server.cli.PKIServerCLI', 
'ca-user-add', '--full-name', 'CA-server.example.com-8443', '--type', 
'agentType', '--state', '1', '--debug', 'CA-server.example.com-8443']' returned 
non-zero exit status 255.
  File "/usr/lib/python3.6/site-packages/pki/server/pkispawn.py", line 575, in 
main
scriptlet.spawn(deployer)
  File 
"/usr/lib/python3.6/site-packages/pki/server/deployment/scriptlets/configuration.py",
 line 740, in spawn
deployer.setup_subsystem_user(instance, subsystem, 
system_certs['subsystem'])
  File "/usr/lib/python3.6/site-packages/pki/server/deployment/__init__.py", 
line 1040, in setup_subsystem_user
state='1')
  File "/usr/lib/python3.6/site-packages/pki/server/subsystem.py", line 1521, 
in add_user
capture_output=True)
  File "/usr/lib/python3.6/site-packages/pki/server/subsystem.py", line 1653, 
in run
check=True)
  File "/usr/lib64/python3.6/subprocess.py", line 438, in run
output=stdout, stderr=stderr)


2022-01-28T17:44:16Z CRITICAL Failed to configure CA instance

So while a lot further than before, it still fails, but much later in
the install.

Any ideas on this new development?

Cheers,
b.




signature.asc
Description: This is a digitally 

[Freeipa-users] Re: Need help with confusing query results

2022-01-28 Thread Thierry Bordaz via FreeIPA-users

Hi Edward,

I think you may try to create the task manually

ldapmodify -D "cn=directory manager" -w ... -a <,cn=entryuuid task,cn=tasks,cn=config
objectClass: top
objectClass: extensibleObject
basedn: 
cn: entryuuid_fixup_
!

If you want to fixup only specific entries you many add the following 
attribute to the task entry


filter: 

regards
thierry

On 1/28/22 5:35 PM, Edward Valley via FreeIPA-users wrote:

Hi,
Thanks for the tip.
Any workaround in the mean time?
I couldn't find one.
Thanks
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure


[Freeipa-users] Re: Need help with confusing query results

2022-01-28 Thread Edward Valley via FreeIPA-users
Hi,
Thanks for the tip.
Any workaround in the mean time?
I couldn't find one.
Thanks
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure


[Freeipa-users] Re: 1 server not syncing with the others

2022-01-28 Thread Rob Crittenden via FreeIPA-users
Russell Jones via FreeIPA-users wrote:
> Thanks,
> 
> I ended up finding the issue from another mailing list post. ntpd was
> not running on this host and the time got skewed too much from the other
> masters.
> 
> For what it's worth, the ipa-healthcheck script did not catch this
> issue. Might be something to add?

It would be nice but syncing time can be quite slow and, AFAIK, there is
no way in advance to know if there is a time source available. So check
against what?

rob

> 
> On Fri, Jan 28, 2022 at 2:49 AM Florence Blanc-Renaud  > wrote:
> 
> Hi,
> you can find troubleshooting tips in
> 
> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/linux_domain_identity_authentication_and_policy_guide/trouble-gen-replication
> 
> HTH,
> flo
> 
> On Thu, Jan 27, 2022 at 6:54 PM Russell Jones via FreeIPA-users
>  > wrote:
> 
> Hi all,
> 
> I have a setup of 4 FreeIPA servers, version 4.6.5, all on CentOS 7.
> 
> I've discovered that #4 is not syncing a new "video" group I
> created, while the other 3 all have the group.
> 
> When looking at dirsrv error log, I am seeing the following
> after running an ipactl stop / ipactl start:
> 
> [27/Jan/2022:11:35:55.158724429 -0600] - ERR - set_krb5_creds -
> Could not get initial credentials for principal
> [ldap/freeipa4.clus...@us.ep.corp.LOCAL] in keytab
> [FILE:/etc/dirsrv/ds.keytab]: -1765328228 (Cannot contact any
> KDC for requested realm)
> [27/Jan/2022:11:35:55.169790450 -0600] - INFO - slapd_daemon -
> slapd started.  Listening on All Interfaces port 389 for LDAP
> requests
> [27/Jan/2022:11:35:55.173079823 -0600] - INFO - slapd_daemon -
> Listening on All Interfaces port 636 for LDAPS requests
> [27/Jan/2022:11:35:55.175096801 -0600] - INFO - slapd_daemon -
> Listening on /var/run/slapd-US-EP-CORP-LOCAL.socket for LDAPI
> requests
> [27/Jan/2022:11:35:55.235218894 -0600] - ERR -
> schema-compat-plugin - schema-compat-plugin tree scan will start
> in about 5 seconds!
> [27/Jan/2022:11:35:58.368835716 -0600] - ERR -
> NSMMReplicationPlugin - bind_and_check_pwp -
> agmt="cn=meTofreeipa.us.ep.corp.local" (freeipa:389) -
> Replication bind with GSSAPI auth failed: LDAP error 49 (Invalid
> credentials) ()
> 
> 
> I am unsure what the issue is or how to resolve this. Could I
> get some assistance with being pointed in the right direction?
> 
> Thank you!
> ___
> FreeIPA-users mailing list --
> freeipa-users@lists.fedorahosted.org
> 
> To unsubscribe send an email to
> freeipa-users-le...@lists.fedorahosted.org
> 
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines:
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> 
> https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
> 
> 
> ___
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure
> 
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure


[Freeipa-users] Re: SSL error after upgrade

2022-01-28 Thread Nathanaël Blanchet via FreeIPA-users

Thanks to all for the fix, you save my day!

Le 25/12/2021 à 17:06, Dungan, Scott A. via FreeIPA-users a écrit :


Hi, Per.

I ran into the same problem and Alexander referred me to this link: 
https://www.mail-archive.com/freeipa-users@lists.fedorahosted.org/msg12583.html


The fix  for us was is pretty easy:

 1. Make a backup of /etc/pki/pki-tomcat/server.xml
 2. On lines 129 and 171 of server.xml, you’ll see a value for
“secret=” and “sharedSecret=.” Those values will be different and
that is the cause of the problem. Both values should match what is
found in the ProxyPassMatch statements located in the file
/etc/httpd/conf.d/ipa-pki-proxy.conf. In my case, the value for
secret= was correct and I just had to change the sharedSecert= to
match.
 3. Restart services with ipactl restart

-Scott

*From:* Per Qvindesland via FreeIPA-users 


*Sent:* Wednesday, December 22, 2021 7:22 AM
*To:* FreeIPA users list 
*Cc:* Per Qvindesland 
*Subject:* [Freeipa-users] SSL error after upgrade

Hi All

After an update to 4.9.6-10, I am unable to view any of the 
certificates that the IPA server has signed, I get error: An error has 
occurred (IPA Error 4301: CertificateOperationError) when I click on 
Authnticaiton -> Certificates, if I click on "Certificate Autorities" 
then I get popup message with the error "Failed to authenticate to CA 
REST API" and "An error has occurred (IPA Error 4016: 
RemoteRetrieveError)" is showing on the screen.


ipactl status is showing everything as running:

ipactl status

Directory Service: RUNNING

krb5kdc Service: RUNNING

kadmin Service: RUNNING

named Service: RUNNING

httpd Service: RUNNING

ipa-custodia Service: RUNNING

pki-tomcatd Service: RUNNING

smb Service: RUNNING

winbind Service: RUNNING

ipa-otpd Service: RUNNING

ipa-dnskeysyncd Service: RUNNING

ipa: INFO: The ipactl command was successful

Does anyone know what's causing this error?

I ran ipa-healthcheck and pasted the output below, it reports that 
it's missing SRV records but the IPA server is the DNS server and it 
has the SRV records.


Regards

Per

ipa-healthcheck

ra.get_certificate(): Request failed with status 403: Non-2xx response 
from CA REST API: 403.  (403)


ra.get_certificate(): Request failed with status 403: Non-2xx response 
from CA REST API: 403.  (403)


ra.get_certificate(): Request failed with status 403: Non-2xx response 
from CA REST API: 403.  (403)


ra.get_certificate(): Request failed with status 403: Non-2xx response 
from CA REST API: 403.  (403)


ra.get_certificate(): Request failed with status 403: Non-2xx response 
from CA REST API: 403.  (403)


ra.get_certificate(): Request failed with status 403: Non-2xx response 
from CA REST API: 403.  (403)


ra.get_certificate(): Request failed with status 403: Non-2xx response 
from CA REST API: 403.  (403)


ra.get_certificate(): Request failed with status 403: Non-2xx response 
from CA REST API: 403.  (403)


ra.get_certificate(): Request failed with status 403: Non-2xx response 
from CA REST API: 403.  (403)


ra.get_certificate(): Request failed with status 403: Non-2xx response 
from CA REST API: 403.  (403)


[

  {

    "source": "ipahealthcheck.dogtag.ca",

    "check": "DogtagCertsConnectivityCheck",

    "result": "ERROR",

    "uuid": "ac0200eb-3ec8-405f-ba5e-523cbb40ad6b",

    "when": "20211222151125Z",

    "duration": "0.016156",

    "kw": {

  "msg": "Request for certificate failed, Certificate operation 
cannot be completed: Request failed with status 403: Non-2xx response 
from CA REST API: 403.  (403)"


    }

  },

  {

    "source": "ipahealthcheck.ipa.certs",

    "check": "IPACertRevocation",

    "result": "ERROR",

    "uuid": "2f010c35-7d7d-431f-89b0-c342516cf296",

    "when": "20211222151130Z",

    "duration": "0.412221",

    "kw": {

  "key": "20211104170633",

  "serial": 7,

  "error": "Certificate operation cannot be completed: Request 
failed with status 403: Non-2xx response from CA REST API: 403.  (403)",


  "msg": "Request for certificate serial number {serial} in 
request {key} failed: {error}"


    }

  },

  {

    "source": "ipahealthcheck.ipa.certs",

    "check": "IPACertRevocation",

"result": "ERROR",

    "uuid": "10a946e2-e511-417a-b189-a66f1b555470",

"when": "20211222151130Z",

    "duration": "0.519989",

    "kw": {

  "key": "20211104170628",

  "serial": 5,

  "error": "Certificate operation cannot be completed: Request 
failed with status 403: Non-2xx response from CA REST API: 403.  (403)",


  "msg": "Request for certificate serial number {serial} in 
request {key} failed: {error}"


    }

  },

  {

    "source": "ipahealthcheck.ipa.certs",

    "check": "IPACertRevocation",

"result": "ERROR",

    "uuid": "7c85e383-8508-4b8e-a10b-838b0b70eb73",

"when": "20211222151130Z",

    "duration": "0.618106",

    "kw": {

  "key": "20211104170629",

  "serial": 2,

  "error": "Certificate operation cannot be co

[Freeipa-users] Re: missing attribute "krbPrincipalName" required by object class "ipaKrbPrincipal"

2022-01-28 Thread Florence Blanc-Renaud via FreeIPA-users
Hi,
you can do
(on another server)
$ ipa server-del --force server.example.com
This should clean up all references to server.example.com

(on server.example.com)
$ ipa-client-install --uninstall -U
$ kdestroy -A
$ ipa-client-install ...
$ kinit admin
$ ipa-replica-install ...

HTH,
flo

On Fri, Jan 28, 2022 at 2:56 PM Brian J. Murrell via FreeIPA-users <
freeipa-users@lists.fedorahosted.org> wrote:

> On Tue, 2022-01-25 at 16:45 +0200, Alexander Bokovoy wrote:
> >
> >  On another server, use the ipa server-del command to delete
> >  server.example.com from the topology:
>
> Indeed, I missed this part.  :-( I suppose this cannot be done now that
> the machine has been redployed as a client correct?
>
> # ipa host-show server.example.com
>   Host name: server.example.com
>   Platform: x86_64
>   Operating system: 4.18.0-305.25.1.el8_4.x86_64
>   Principal name: host/server.example@example.com
>   Principal alias: host/server.example@example.com
>   SSH public key fingerprint: [redacted]
>   Password: False
>   Member of host-groups: ipaservers
>   Member of HBAC rule: all_allow_mail_services
>   Keytab: True
>   Managed by: server.example.com
> # ipa server-show server.example.com
> ipa: ERROR: server.example.com: server not found
> # ipa server-find
> 
> 1 IPA server matched
> 
>   Server name: server-staging.example.com
>   Min domain level: 1
>   Max domain level: 1
> 
> Number of entries returned 1
> 
>
> Could I attempt to add as a replica again, have it fail and then would
> I be able to do the "ipa server-del"?
>
> > Does using a raw LDAP delete help?
> >
> >   ldapdelete -D cn=directory\ manager -W
> > krbprincipalname=ldap/server.example@example.com,cn=services,cn=a
> > ccounts,dc=example,dc=com
>
> I have not tried yet, pending the answer to the above questions.  I
> don't want to much around too much under the hood before I have to.
>
> > If not, you might need to temporarily fix the LDAP entry schema
> > consistency before deleting the object. It means you'd need to add
> > krbPrincipalName attribute back.
>
> I have no idea how to do that.  I have not mucked around with LDAP
> directly.
>
> Cheers,
> b.
>
>
> ___
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure


[Freeipa-users] Re: 1 server not syncing with the others

2022-01-28 Thread Russell Jones via FreeIPA-users
Thanks,

I ended up finding the issue from another mailing list post. ntpd was not
running on this host and the time got skewed too much from the other
masters.

For what it's worth, the ipa-healthcheck script did not catch this issue.
Might be something to add?

On Fri, Jan 28, 2022 at 2:49 AM Florence Blanc-Renaud 
wrote:

> Hi,
> you can find troubleshooting tips in
> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/linux_domain_identity_authentication_and_policy_guide/trouble-gen-replication
>
> HTH,
> flo
>
> On Thu, Jan 27, 2022 at 6:54 PM Russell Jones via FreeIPA-users <
> freeipa-users@lists.fedorahosted.org> wrote:
>
>> Hi all,
>>
>> I have a setup of 4 FreeIPA servers, version 4.6.5, all on CentOS 7.
>>
>> I've discovered that #4 is not syncing a new "video" group I created,
>> while the other 3 all have the group.
>>
>> When looking at dirsrv error log, I am seeing the following after running
>> an ipactl stop / ipactl start:
>>
>> [27/Jan/2022:11:35:55.158724429 -0600] - ERR - set_krb5_creds - Could not
>> get initial credentials for principal
>> [ldap/freeipa4.clus...@us.ep.corp.LOCAL] in keytab
>> [FILE:/etc/dirsrv/ds.keytab]: -1765328228 (Cannot contact any KDC for
>> requested realm)
>> [27/Jan/2022:11:35:55.169790450 -0600] - INFO - slapd_daemon - slapd
>> started.  Listening on All Interfaces port 389 for LDAP requests
>> [27/Jan/2022:11:35:55.173079823 -0600] - INFO - slapd_daemon - Listening
>> on All Interfaces port 636 for LDAPS requests
>> [27/Jan/2022:11:35:55.175096801 -0600] - INFO - slapd_daemon - Listening
>> on /var/run/slapd-US-EP-CORP-LOCAL.socket for LDAPI requests
>> [27/Jan/2022:11:35:55.235218894 -0600] - ERR - schema-compat-plugin -
>> schema-compat-plugin tree scan will start in about 5 seconds!
>> [27/Jan/2022:11:35:58.368835716 -0600] - ERR - NSMMReplicationPlugin -
>> bind_and_check_pwp - agmt="cn=meTofreeipa.us.ep.corp.local" (freeipa:389) -
>> Replication bind with GSSAPI auth failed: LDAP error 49 (Invalid
>> credentials) ()
>>
>>
>> I am unsure what the issue is or how to resolve this. Could I get some
>> assistance with being pointed in the right direction?
>>
>> Thank you!
>> ___
>> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
>> To unsubscribe send an email to
>> freeipa-users-le...@lists.fedorahosted.org
>> Fedora Code of Conduct:
>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives:
>> https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
>> Do not reply to spam on the list, report it:
>> https://pagure.io/fedora-infrastructure
>>
>
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure


[Freeipa-users] Re: 403 Error

2022-01-28 Thread Christian Reiss via FreeIPA-users

Hey,

thanks for pointing that out.
Issue resolved!

For google:
  1. Look at /etc/httpd/conf.d/ipa-pki-proxy.conf for secret.
  2. Fix /etc/pki/pki-tomcat/server.xml, 4 occurance of those secrets.
  3. Restart tomcat services
  4. Profit.

Cheers!
-Chris.

On 28/01/2022 14:21, Rob Crittenden wrote:

Christian Reiss via FreeIPA-users wrote:

Hey folks,

happyily using FreeIPA in my personal hobbyist space across 50vms and 8
hosts. It worked like a charm. Ever since a few days ago I am unable to
delete hosts, disabling/ enabling users for example works, but not
deleting hosts. I am using AlmaLinux 8 with vendor-supplied FreeIPA
version.

I duckduckgo'd around the net, tried to solve the issue myself. But no
errors our there helped me debug. I think I found the issue with
ipa-healthcheck, but I am unsure on how to fix. This is the output:


Start with this thread,
https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/thread/NZLD5WHI4GCM2B437WPPD4HIHSCJT45F/#NCQWDDUK5X3FFL7FQ5V7D5HOOLXUFDWI

rob



 8<     8<     8<     8<     8< 

Internal server error 403 Client Error: 403 for url:
http://auth1.alpha-labs.net:80/ca/rest/securityDomain/domainInfo
Directory Server CA certificate not found, assuming 3rd party
ra.get_certificate(): Request failed with status 403: Non-2xx response
from CA REST API: 403.  (403)
ra.get_certificate(): Request failed with status 403: Non-2xx response
from CA REST API: 403.  (403)
ra.get_certificate(): Request failed with status 403: Non-2xx response
from CA REST API: 403.  (403)
ra.get_certificate(): Request failed with status 403: Non-2xx response
from CA REST API: 403.  (403)
ra.get_certificate(): Request failed with status 403: Non-2xx response
from CA REST API: 403.  (403)
ra.get_certificate(): Request failed with status 403: Non-2xx response
from CA REST API: 403.  (403)
ra.get_certificate(): Request failed with status 403: Non-2xx response
from CA REST API: 403.  (403)
ra.get_certificate(): Request failed with status 403: Non-2xx response
from CA REST API: 403.  (403)
ra.get_certificate(): Request failed with status 403: Non-2xx response
from CA REST API: 403.  (403)
ra.get_certificate(): Request failed with status 403: Non-2xx response
from CA REST API: 403.  (403)
[
   {
     "source": "pki.server.healthcheck.meta.csconfig",
     "check": "CADogtagCertsConfigCheck",
     "result": "ERROR",
     "uuid": "c76c5f53-1869-4cd5-95e3-dd7f3e0b7e0c",
     "when": "20220128091051Z",
     "duration": "0.361963",
     "kw": {
   "key": "ca_signing",
   "nickname": "caSigningCert cert-pki-ca",
   "directive": "ca.signing.cert",
   "configfile": "/var/lib/pki/pki-tomcat/ca/conf/CS.cfg",
   "msg": "Certificate 'caSigningCert cert-pki-ca' does not match the
value of ca.signing.cert in /var/lib/pki/pki-tomcat/ca/conf/CS.cfg"
     }
   },
   {
     "source": "ipahealthcheck.dogtag.ca",
     "check": "DogtagCertsConnectivityCheck",
     "result": "ERROR",
     "uuid": "e98075a4-5d85-4ccf-a97e-b202fcc92789",
     "when": "20220128091054Z",
     "duration": "0.566005",
     "kw": {
   "msg": "Request for certificate failed, Certificate operation
cannot be completed: Request failed with status 403: Non-2xx response
from CA REST API: 403.  (403)"
     }
   },
   {
     "source": "ipahealthcheck.ds.replication",
     "check": "ReplicationCheck",
     "result": "WARNING",
     "uuid": "d9dcf871-1a5d-47a6-8d2e-bcf4f61f09d1",
     "when": "20220128091056Z",
     "duration": "0.788714",
     "kw": {
   "key": "DSREPLLE0002",
   "items": [
     "Replication",
     "Conflict Entries"
   ],
   "msg": "There were 4 conflict entries found under the replication
suffix \"dc=alpha-labs,dc=net\"."
     }
   },
   {
     "source": "ipahealthcheck.ipa.certs",
     "check": "IPADogtagCertsMatchCheck",
     "result": "ERROR",
     "uuid": "1c96ee54-e8ca-4045-9bfc-294c261e4ab8",
     "when": "20220128091101Z",
     "duration": "0.198242",
     "kw": {
   "key": "caSigningCert cert-pki-ca",
   "nickname": "caSigningCert cert-pki-ca",
   "dbdir": "/etc/pki/pki-tomcat/alias",
   "msg": "{nickname} certificate in NSS DB {dbdir} does not match
entry in LDAP"
     }
   },
   {
     "source": "ipahealthcheck.ipa.certs",
     "check": "IPACertRevocation",
     "result": "ERROR",
     "uuid": "17140733-ba3f-4d34-a48c-3b1e159b3488",
     "when": "20220128091105Z",
     "duration": "0.731259",
     "kw": {
   "key": "20201208073945",
   "serial": 1073676292,
   "error": "Certificate operation cannot be completed: Request
failed with status 403: Non-2xx response from CA REST API: 403.  (403)",
   "msg": "Request for certificate serial number {serial} in request
{key} failed: {error}"
     }
   },
   {
     "source": "ipahealthcheck.ipa.certs",
     "check": "IPACertRevocation",
     "result": "ERROR",
     "uuid": "9833fce2-5f98-480b-9a69-d2d41db21ef0",
     "when": "2022012809110

[Freeipa-users] Re: missing attribute "krbPrincipalName" required by object class "ipaKrbPrincipal"

2022-01-28 Thread Brian J. Murrell via FreeIPA-users
On Tue, 2022-01-25 at 16:45 +0200, Alexander Bokovoy wrote:
> 
>  On another server, use the ipa server-del command to delete
>  server.example.com from the topology:

Indeed, I missed this part.  :-( I suppose this cannot be done now that
the machine has been redployed as a client correct?

# ipa host-show server.example.com
  Host name: server.example.com
  Platform: x86_64
  Operating system: 4.18.0-305.25.1.el8_4.x86_64
  Principal name: host/server.example@example.com
  Principal alias: host/server.example@example.com
  SSH public key fingerprint: [redacted]
  Password: False
  Member of host-groups: ipaservers
  Member of HBAC rule: all_allow_mail_services
  Keytab: True
  Managed by: server.example.com
# ipa server-show server.example.com
ipa: ERROR: server.example.com: server not found
# ipa server-find

1 IPA server matched

  Server name: server-staging.example.com
  Min domain level: 1
  Max domain level: 1

Number of entries returned 1


Could I attempt to add as a replica again, have it fail and then would
I be able to do the "ipa server-del"?

> Does using a raw LDAP delete help?
> 
>   ldapdelete -D cn=directory\ manager -W
> krbprincipalname=ldap/server.example@example.com,cn=services,cn=a
> ccounts,dc=example,dc=com

I have not tried yet, pending the answer to the above questions.  I
don't want to much around too much under the hood before I have to.

> If not, you might need to temporarily fix the LDAP entry schema
> consistency before deleting the object. It means you'd need to add
> krbPrincipalName attribute back.

I have no idea how to do that.  I have not mucked around with LDAP
directly.

Cheers,
b.




signature.asc
Description: This is a digitally signed message part
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure


[Freeipa-users] Re: 403 Error

2022-01-28 Thread Rob Crittenden via FreeIPA-users
Christian Reiss via FreeIPA-users wrote:
> Hey folks,
> 
> happyily using FreeIPA in my personal hobbyist space across 50vms and 8
> hosts. It worked like a charm. Ever since a few days ago I am unable to
> delete hosts, disabling/ enabling users for example works, but not
> deleting hosts. I am using AlmaLinux 8 with vendor-supplied FreeIPA
> version.
> 
> I duckduckgo'd around the net, tried to solve the issue myself. But no
> errors our there helped me debug. I think I found the issue with
> ipa-healthcheck, but I am unsure on how to fix. This is the output:

Start with this thread,
https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/thread/NZLD5WHI4GCM2B437WPPD4HIHSCJT45F/#NCQWDDUK5X3FFL7FQ5V7D5HOOLXUFDWI

rob

> 
>  8<     8<     8<     8<     8< 
> 
> Internal server error 403 Client Error: 403 for url:
> http://auth1.alpha-labs.net:80/ca/rest/securityDomain/domainInfo
> Directory Server CA certificate not found, assuming 3rd party
> ra.get_certificate(): Request failed with status 403: Non-2xx response
> from CA REST API: 403.  (403)
> ra.get_certificate(): Request failed with status 403: Non-2xx response
> from CA REST API: 403.  (403)
> ra.get_certificate(): Request failed with status 403: Non-2xx response
> from CA REST API: 403.  (403)
> ra.get_certificate(): Request failed with status 403: Non-2xx response
> from CA REST API: 403.  (403)
> ra.get_certificate(): Request failed with status 403: Non-2xx response
> from CA REST API: 403.  (403)
> ra.get_certificate(): Request failed with status 403: Non-2xx response
> from CA REST API: 403.  (403)
> ra.get_certificate(): Request failed with status 403: Non-2xx response
> from CA REST API: 403.  (403)
> ra.get_certificate(): Request failed with status 403: Non-2xx response
> from CA REST API: 403.  (403)
> ra.get_certificate(): Request failed with status 403: Non-2xx response
> from CA REST API: 403.  (403)
> ra.get_certificate(): Request failed with status 403: Non-2xx response
> from CA REST API: 403.  (403)
> [
>   {
>     "source": "pki.server.healthcheck.meta.csconfig",
>     "check": "CADogtagCertsConfigCheck",
>     "result": "ERROR",
>     "uuid": "c76c5f53-1869-4cd5-95e3-dd7f3e0b7e0c",
>     "when": "20220128091051Z",
>     "duration": "0.361963",
>     "kw": {
>   "key": "ca_signing",
>   "nickname": "caSigningCert cert-pki-ca",
>   "directive": "ca.signing.cert",
>   "configfile": "/var/lib/pki/pki-tomcat/ca/conf/CS.cfg",
>   "msg": "Certificate 'caSigningCert cert-pki-ca' does not match the
> value of ca.signing.cert in /var/lib/pki/pki-tomcat/ca/conf/CS.cfg"
>     }
>   },
>   {
>     "source": "ipahealthcheck.dogtag.ca",
>     "check": "DogtagCertsConnectivityCheck",
>     "result": "ERROR",
>     "uuid": "e98075a4-5d85-4ccf-a97e-b202fcc92789",
>     "when": "20220128091054Z",
>     "duration": "0.566005",
>     "kw": {
>   "msg": "Request for certificate failed, Certificate operation
> cannot be completed: Request failed with status 403: Non-2xx response
> from CA REST API: 403.  (403)"
>     }
>   },
>   {
>     "source": "ipahealthcheck.ds.replication",
>     "check": "ReplicationCheck",
>     "result": "WARNING",
>     "uuid": "d9dcf871-1a5d-47a6-8d2e-bcf4f61f09d1",
>     "when": "20220128091056Z",
>     "duration": "0.788714",
>     "kw": {
>   "key": "DSREPLLE0002",
>   "items": [
>     "Replication",
>     "Conflict Entries"
>   ],
>   "msg": "There were 4 conflict entries found under the replication
> suffix \"dc=alpha-labs,dc=net\"."
>     }
>   },
>   {
>     "source": "ipahealthcheck.ipa.certs",
>     "check": "IPADogtagCertsMatchCheck",
>     "result": "ERROR",
>     "uuid": "1c96ee54-e8ca-4045-9bfc-294c261e4ab8",
>     "when": "20220128091101Z",
>     "duration": "0.198242",
>     "kw": {
>   "key": "caSigningCert cert-pki-ca",
>   "nickname": "caSigningCert cert-pki-ca",
>   "dbdir": "/etc/pki/pki-tomcat/alias",
>   "msg": "{nickname} certificate in NSS DB {dbdir} does not match
> entry in LDAP"
>     }
>   },
>   {
>     "source": "ipahealthcheck.ipa.certs",
>     "check": "IPACertRevocation",
>     "result": "ERROR",
>     "uuid": "17140733-ba3f-4d34-a48c-3b1e159b3488",
>     "when": "20220128091105Z",
>     "duration": "0.731259",
>     "kw": {
>   "key": "20201208073945",
>   "serial": 1073676292,
>   "error": "Certificate operation cannot be completed: Request
> failed with status 403: Non-2xx response from CA REST API: 403.  (403)",
>   "msg": "Request for certificate serial number {serial} in request
> {key} failed: {error}"
>     }
>   },
>   {
>     "source": "ipahealthcheck.ipa.certs",
>     "check": "IPACertRevocation",
>     "result": "ERROR",
>     "uuid": "9833fce2-5f98-480b-9a69-d2d41db21ef0",
>     "when": "20220128091105Z",
>     "duration": "0.888676",
>     "kw": {
>   "key": "20201208073937",
>   "serial": 1073676293,
>   "error": "Certificat

[Freeipa-users] 403 Error

2022-01-28 Thread Christian Reiss via FreeIPA-users

Hey folks,

happyily using FreeIPA in my personal hobbyist space across 50vms and 8 
hosts. It worked like a charm. Ever since a few days ago I am unable to 
delete hosts, disabling/ enabling users for example works, but not 
deleting hosts. I am using AlmaLinux 8 with vendor-supplied FreeIPA version.


I duckduckgo'd around the net, tried to solve the issue myself. But no 
errors our there helped me debug. I think I found the issue with 
ipa-healthcheck, but I am unsure on how to fix. This is the output:


 8<     8<     8<     8<     8< 

Internal server error 403 Client Error: 403 for url: 
http://auth1.alpha-labs.net:80/ca/rest/securityDomain/domainInfo

Directory Server CA certificate not found, assuming 3rd party
ra.get_certificate(): Request failed with status 403: Non-2xx response 
from CA REST API: 403.  (403)
ra.get_certificate(): Request failed with status 403: Non-2xx response 
from CA REST API: 403.  (403)
ra.get_certificate(): Request failed with status 403: Non-2xx response 
from CA REST API: 403.  (403)
ra.get_certificate(): Request failed with status 403: Non-2xx response 
from CA REST API: 403.  (403)
ra.get_certificate(): Request failed with status 403: Non-2xx response 
from CA REST API: 403.  (403)
ra.get_certificate(): Request failed with status 403: Non-2xx response 
from CA REST API: 403.  (403)
ra.get_certificate(): Request failed with status 403: Non-2xx response 
from CA REST API: 403.  (403)
ra.get_certificate(): Request failed with status 403: Non-2xx response 
from CA REST API: 403.  (403)
ra.get_certificate(): Request failed with status 403: Non-2xx response 
from CA REST API: 403.  (403)
ra.get_certificate(): Request failed with status 403: Non-2xx response 
from CA REST API: 403.  (403)

[
  {
"source": "pki.server.healthcheck.meta.csconfig",
"check": "CADogtagCertsConfigCheck",
"result": "ERROR",
"uuid": "c76c5f53-1869-4cd5-95e3-dd7f3e0b7e0c",
"when": "20220128091051Z",
"duration": "0.361963",
"kw": {
  "key": "ca_signing",
  "nickname": "caSigningCert cert-pki-ca",
  "directive": "ca.signing.cert",
  "configfile": "/var/lib/pki/pki-tomcat/ca/conf/CS.cfg",
  "msg": "Certificate 'caSigningCert cert-pki-ca' does not match 
the value of ca.signing.cert in /var/lib/pki/pki-tomcat/ca/conf/CS.cfg"

}
  },
  {
"source": "ipahealthcheck.dogtag.ca",
"check": "DogtagCertsConnectivityCheck",
"result": "ERROR",
"uuid": "e98075a4-5d85-4ccf-a97e-b202fcc92789",
"when": "20220128091054Z",
"duration": "0.566005",
"kw": {
  "msg": "Request for certificate failed, Certificate operation 
cannot be completed: Request failed with status 403: Non-2xx response 
from CA REST API: 403.  (403)"

}
  },
  {
"source": "ipahealthcheck.ds.replication",
"check": "ReplicationCheck",
"result": "WARNING",
"uuid": "d9dcf871-1a5d-47a6-8d2e-bcf4f61f09d1",
"when": "20220128091056Z",
"duration": "0.788714",
"kw": {
  "key": "DSREPLLE0002",
  "items": [
"Replication",
"Conflict Entries"
  ],
  "msg": "There were 4 conflict entries found under the replication 
suffix \"dc=alpha-labs,dc=net\"."

}
  },
  {
"source": "ipahealthcheck.ipa.certs",
"check": "IPADogtagCertsMatchCheck",
"result": "ERROR",
"uuid": "1c96ee54-e8ca-4045-9bfc-294c261e4ab8",
"when": "20220128091101Z",
"duration": "0.198242",
"kw": {
  "key": "caSigningCert cert-pki-ca",
  "nickname": "caSigningCert cert-pki-ca",
  "dbdir": "/etc/pki/pki-tomcat/alias",
  "msg": "{nickname} certificate in NSS DB {dbdir} does not match 
entry in LDAP"

}
  },
  {
"source": "ipahealthcheck.ipa.certs",
"check": "IPACertRevocation",
"result": "ERROR",
"uuid": "17140733-ba3f-4d34-a48c-3b1e159b3488",
"when": "20220128091105Z",
"duration": "0.731259",
"kw": {
  "key": "20201208073945",
  "serial": 1073676292,
  "error": "Certificate operation cannot be completed: Request 
failed with status 403: Non-2xx response from CA REST API: 403.  (403)",
  "msg": "Request for certificate serial number {serial} in request 
{key} failed: {error}"

}
  },
  {
"source": "ipahealthcheck.ipa.certs",
"check": "IPACertRevocation",
"result": "ERROR",
"uuid": "9833fce2-5f98-480b-9a69-d2d41db21ef0",
"when": "20220128091105Z",
"duration": "0.888676",
"kw": {
  "key": "20201208073937",
  "serial": 1073676293,
  "error": "Certificate operation cannot be completed: Request 
failed with status 403: Non-2xx response from CA REST API: 403.  (403)",
  "msg": "Request for certificate serial number {serial} in request 
{key} failed: {error}"

}
  },
  {
"source": "ipahealthcheck.ipa.certs",
"check": "IPACertRevocation",
"result": "ERROR",
"uuid": "c3f1b686-a74b-42d6-8b55-b6fe36671933",
"when": "20220128091105Z",
"duration": "1.065141",
"kw": {

[Freeipa-users] Re: 1 server not syncing with the others

2022-01-28 Thread Florence Blanc-Renaud via FreeIPA-users
Hi,
you can find troubleshooting tips in
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/linux_domain_identity_authentication_and_policy_guide/trouble-gen-replication

HTH,
flo

On Thu, Jan 27, 2022 at 6:54 PM Russell Jones via FreeIPA-users <
freeipa-users@lists.fedorahosted.org> wrote:

> Hi all,
>
> I have a setup of 4 FreeIPA servers, version 4.6.5, all on CentOS 7.
>
> I've discovered that #4 is not syncing a new "video" group I created,
> while the other 3 all have the group.
>
> When looking at dirsrv error log, I am seeing the following after running
> an ipactl stop / ipactl start:
>
> [27/Jan/2022:11:35:55.158724429 -0600] - ERR - set_krb5_creds - Could not
> get initial credentials for principal
> [ldap/freeipa4.clus...@us.ep.corp.LOCAL] in keytab
> [FILE:/etc/dirsrv/ds.keytab]: -1765328228 (Cannot contact any KDC for
> requested realm)
> [27/Jan/2022:11:35:55.169790450 -0600] - INFO - slapd_daemon - slapd
> started.  Listening on All Interfaces port 389 for LDAP requests
> [27/Jan/2022:11:35:55.173079823 -0600] - INFO - slapd_daemon - Listening
> on All Interfaces port 636 for LDAPS requests
> [27/Jan/2022:11:35:55.175096801 -0600] - INFO - slapd_daemon - Listening
> on /var/run/slapd-US-EP-CORP-LOCAL.socket for LDAPI requests
> [27/Jan/2022:11:35:55.235218894 -0600] - ERR - schema-compat-plugin -
> schema-compat-plugin tree scan will start in about 5 seconds!
> [27/Jan/2022:11:35:58.368835716 -0600] - ERR - NSMMReplicationPlugin -
> bind_and_check_pwp - agmt="cn=meTofreeipa.us.ep.corp.local" (freeipa:389) -
> Replication bind with GSSAPI auth failed: LDAP error 49 (Invalid
> credentials) ()
>
>
> I am unsure what the issue is or how to resolve this. Could I get some
> assistance with being pointed in the right direction?
>
> Thank you!
> ___
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure