[Freeipa-users] Re: Recommendations for FreeIPA implemenation in existing organization

[Juan Pablo via FreeIPA-users]

Thomas,
you have several ways to do so, each has its own pro and cons. Start by
taking a look here :
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/windows_integration_guide/introduction
I strongly encourage you to read quickly the whole manual just from the
above to get an idea of which scenario fits better to your needs, normally,
but not always, Indirect integration using AD trust is the best (you can
find that on the link ).
Once you have that sorted, set a testing environment to try the features
you need/want, there are several guidelines, one but outdated:
https://www.freeipa.org/page/Active_Directory_trust_setup . 97% there still
works.

hope that gives you something to start.
regards,
--
Juan Pablo Máscolo
IRC: Kal3ssiN




El mar., 14 jul. 2020 a las 3:38, Thomas Schneider via FreeIPA-users (<
freeipa-users@lists.fedorahosted.org>) escribió:

> Hello,
>
> I'm planning to implement FreeIPA in an existing organization that is
> providing services
> - DNS
> - Active Directory
> - LDAP
> - Certificates
>
> My question for the experts is:
> What is your best practice / recommendation for implementation of
> FreeIPA considering the existing services?
> Should I simply *not activate* services in FreeIPA that already exist,
> e.g. DNS, Certificates?
>
> Regards
> Thomas
> ___
> 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
>
___
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

[Freeipa-users] Re: Looking for help to get my IPA server running again

[Florence Blanc-Renaud via FreeIPA-users]

On 7/16/20 4:54 PM, Lorenz Braun wrote:

On 16.07.20 15:50, Florence Blanc-Renaud wrote:

On 7/16/20 3:00 PM, Lorenz Braun via FreeIPA-users wrote:

I was thinking something similar. I tried
```
[root@ipa01 ~]# ipa-cacert-manage renew
Renewing CA certificate, please wait
Error resubmitting certmonger request '20200716071025', please check 
the request manually

The ipa-cacert-manage command failed.
```


Hi,
this command is used to renew IPA CA certificate and not applicable to 
the current situation. IPA CA has ~20 years validity and this cert is 
unlikely to be expired.

Good to know, thanks!

```
[root@ipa01 ~]# getcert list
Number of certificates and requests being tracked: 9.
[...]
Request ID '20200716071025':
 status: CA_UNREACHABLE
This is expected in your case as pki is down, and won't be able to 
manage the certificate renewal request.



 ca-error: Internal error
 stuck: no
 key pair storage: 
type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='caSigningCert 
cert-pki-ca',token='NSS Certificate DB',pin set
 certificate: 
type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='caSigningCert 
cert-pki-ca',token='NSS Certificate DB'

 CA: dogtag-ipa-ca-renew-agent
 issuer: CN=Certificate Authority,O=EXAMPLE.COM
 subject: CN=Certificate Authority,O=EXAMPLE.COM
 expires: 2040-07-16 07:08:27 UTC
 key usage: digitalSignature,nonRepudiation,keyCertSign,cRLSign
 pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad
 post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert 
"caSigningCert cert-pki-ca"

 track: yes
 auto-renew: yes
[...]
```

The other one are all MONITORING and expire at 2022. Since i tried to 
force a new cert maybe this is still okay and the problem lies 
somewhere else?


Then the problem is different. Since the new certs will expire 2022 
(in 2 years), I suspect that they were renewed recently but the 
renewal failed in the middle.


You can refer to [1] in order to ensure that this is the root cause 
and fix the current situation.


HTH,
flo

[1] 
https://floblanc.wordpress.com/2017/09/11/troubleshooting-freeipa-pki-tomcatd-fails-to-start/ 

I have checked and the certificate from /etc/pki/pki-tomcat/alias and 
ldap are the exactly the same. I attached 
/var/log/pki/pki-tomcat/ca/debug. The error message there is different:

```
[16/Jul/2020:16:24:57][profileChangeMonitor]: SignedAuditLogger: event 
CLIENT_ACCESS_SESSION_ESTABLISH

java.net.ConnectException: Connection refused (Connection refused)
     at java.net.PlainSocketImpl.socketConnect(Native Method)
     at 
java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350) 

     at 
java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206) 

     at 
java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)

     at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
     at java.net.Socket.connect(Socket.java:607)
     at java.net.Socket.connect(Socket.java:556)
     at java.net.Socket.(Socket.java:452)
     at java.net.Socket.(Socket.java:262)
     at 
com.netscape.cmscore.ldapconn.PKISocketFactory.makeSSLSocket(PKISocketFactory.java:120) 

     at 
com.netscape.cmscore.ldapconn.PKISocketFactory.makeSocket(PKISocketFactory.java:159) 


     at netscape.ldap.LDAPConnSetupMgr.connectServer(Unknown Source)
     at netscape.ldap.LDAPConnSetupMgr.openSerial(Unknown Source)
     at netscape.ldap.LDAPConnSetupMgr.connect(Unknown Source)
     at netscape.ldap.LDAPConnSetupMgr.openConnection(Unknown Source)
     at netscape.ldap.LDAPConnThread.connect(Unknown Source)
     at netscape.ldap.LDAPConnection.connect(Unknown Source)
     at netscape.ldap.LDAPConnection.connect(Unknown Source)
     at netscape.ldap.LDAPConnection.connect(Unknown Source)
     at 
com.netscape.cmscore.ldapconn.LdapBoundConnection.(LdapBoundConnection.java:82) 

     at 
com.netscape.cmscore.ldapconn.LdapBoundConnFactory$BoundConnection.(LdapBoundConnFactory.java:531) 

     at 
com.netscape.cmscore.ldapconn.LdapBoundConnFactory.makeConnection(LdapBoundConnFactory.java:187) 

     at 
com.netscape.cmscore.ldapconn.LdapBoundConnFactory.getConn(LdapBoundConnFactory.java:332) 

     at 
com.netscape.cmscore.ldapconn.LdapBoundConnFactory.getConn(LdapBoundConnFactory.java:295) 

     at 
com.netscape.cmscore.profile.LDAPProfileSubsystem.run(LDAPProfileSubsystem.java:426) 


     at java.lang.Thread.run(Thread.java:748)
[...]
[16/Jul/2020:16:24:57][profileChangeMonitor]: Can't create master 
connection in LdapBoundConnFactory::getConn! Could not connect to LDAP 
server host ipa01.example.com port 636 Error 
netscape.ldap.LDAPException: Unable to create socket: 
java.net.ConnectException: Connection refused (Connection refused) (-1)
[16/Jul/2020:16:24:57][authorityMonitor]: 

[Freeipa-users] Re: Looking for help to get my IPA server running again

[Florence Blanc-Renaud via FreeIPA-users]

On 7/16/20 3:00 PM, Lorenz Braun via FreeIPA-users wrote:

Hi Flo,

thanks for your feedback. I appreciate it a lot!

On 16.07.20 14:32, Florence Blanc-Renaud wrote:

Hi,
this type of failure can happen when the certificates expire. You can 
check if that's the case using "getcert list" and look at the 
"status:" values that should be MONITORING and the "expires:" date.


Although the manual repair procedure can be quite long, it's possible 
to fix this type of issue. See [1] for instructions.

I was thinking something similar. I tried
```
[root@ipa01 ~]# ipa-cacert-manage renew
Renewing CA certificate, please wait
Error resubmitting certmonger request '20200716071025', please check the 
request manually

The ipa-cacert-manage command failed.
```


Hi,
this command is used to renew IPA CA certificate and not applicable to 
the current situation. IPA CA has ~20 years validity and this cert is 
unlikely to be expired.




```
[root@ipa01 ~]# getcert list
Number of certificates and requests being tracked: 9.
[...]
Request ID '20200716071025':
     status: CA_UNREACHABLE
This is expected in your case as pki is down, and won't be able to 
manage the certificate renewal request.



     ca-error: Internal error
     stuck: no
     key pair storage: 
type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='caSigningCert 
cert-pki-ca',token='NSS Certificate DB',pin set
     certificate: 
type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='caSigningCert 
cert-pki-ca',token='NSS Certificate DB'

     CA: dogtag-ipa-ca-renew-agent
     issuer: CN=Certificate Authority,O=EXAMPLE.COM
     subject: CN=Certificate Authority,O=EXAMPLE.COM
     expires: 2040-07-16 07:08:27 UTC
     key usage: digitalSignature,nonRepudiation,keyCertSign,cRLSign
     pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad
     post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert 
"caSigningCert cert-pki-ca"

     track: yes
     auto-renew: yes
[...]
```

The other one are all MONITORING and expire at 2022. Since i tried to 
force a new cert maybe this is still okay and the problem lies somewhere 
else?


Then the problem is different. Since the new certs will expire 2022 (in 
2 years), I suspect that they were renewed recently but the renewal 
failed in the middle.


You can refer to [1] in order to ensure that this is the root cause and 
fix the current situation.


HTH,
flo

[1] 
https://floblanc.wordpress.com/2017/09/11/troubleshooting-freeipa-pki-tomcatd-fails-to-start/


Unfortunately i can't access [1] since we do not have a subscription. I 
am considering getting one, however its not my decision alone.
Some Clients could sometimes not get kerberos tickets. I couldn't 
quite figure out why.


I used 'ipa-backup --data' in hopes of restoring it on a fresh OS 
with everything working again. Had to upgrade to IPA 4.6.6. It worked 
with 
Can you provide the exact steps that you ran? Performing a data-only 
backup does not save the configuration files and I would like to check 
how the new server was setup.

Sure. Backup was done with `ipa-backup --data --online`

The new server was a fresh CentOS install. Here the steps i did:
```
yum update -y
# reboot

yum install ipa-server -y
ipa-server-install  \
   --ds-password {{ipa_dm_pw}} \
   --admin-password {{ipa_admin_pw}} \
   --realm {{ceg_realm}} \
   --hostname {{inventory_hostname}}.{{ceg_domain}} \
   --domain {{ceg_domain}} \
   --mkhomedir \
   --unattended

ipa-restore --data --backend=userRoot
systemctl stop sssd
find /var/lib/sss/ ! -type d | xargs rm -f
systemctl start sssd
# reboot
```

I should mention that the `ipa ...` commands do not work on the server a 
have also tried on of the clients (unmodified) but it does not accept 
the SSL cert (probably because it is different now).


Best Regards
Lorenz
___
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 


___
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

[Freeipa-users] Re: [EXTERNAL] Re: certmapdata issue

[Shane Frasier via FreeIPA-users]

Thanks for the suggestion Rob!  I posted to the sssd-users mailing list and 
they responded.  Turns out this is a known issue with an existing PR to fix it:
* https://github.com/SSSD/sssd/issues/5135
* https://github.com/SSSD/sssd/pull/1036

I will have to configure FreeIPA to match against full certificates for now, 
and revert to using certmap data once that PR is merged.

Posting here just to close the loop, in case anyone else gets bitten by this 
bug and stumbles upon this exchange.

Thanks again to everyone for all the assistance!

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

[Freeipa-users] Re: Looking for help to get my IPA server running again

[Lorenz Braun via FreeIPA-users]

Hi Flo,

thanks for your feedback. I appreciate it a lot!

On 16.07.20 14:32, Florence Blanc-Renaud wrote:

Hi,
this type of failure can happen when the certificates expire. You can 
check if that's the case using "getcert list" and look at the 
"status:" values that should be MONITORING and the "expires:" date.


Although the manual repair procedure can be quite long, it's possible 
to fix this type of issue. See [1] for instructions.

I was thinking something similar. I tried
```
[root@ipa01 ~]# ipa-cacert-manage renew
Renewing CA certificate, please wait
Error resubmitting certmonger request '20200716071025', please check the 
request manually

The ipa-cacert-manage command failed.
```

```
[root@ipa01 ~]# getcert list
Number of certificates and requests being tracked: 9.
[...]
Request ID '20200716071025':
    status: CA_UNREACHABLE
    ca-error: Internal error
    stuck: no
    key pair storage: 
type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='caSigningCert 
cert-pki-ca',token='NSS Certificate DB',pin set
    certificate: 
type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='caSigningCert 
cert-pki-ca',token='NSS Certificate DB'

    CA: dogtag-ipa-ca-renew-agent
    issuer: CN=Certificate Authority,O=EXAMPLE.COM
    subject: CN=Certificate Authority,O=EXAMPLE.COM
    expires: 2040-07-16 07:08:27 UTC
    key usage: digitalSignature,nonRepudiation,keyCertSign,cRLSign
    pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad
    post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert 
"caSigningCert cert-pki-ca"

    track: yes
    auto-renew: yes
[...]
```

The other one are all MONITORING and expire at 2022. Since i tried to 
force a new cert maybe this is still okay and the problem lies somewhere 
else?
Unfortunately i can't access [1] since we do not have a subscription. I 
am considering getting one, however its not my decision alone.
Some Clients could sometimes not get kerberos tickets. I couldn't 
quite figure out why.


I used 'ipa-backup --data' in hopes of restoring it on a fresh OS 
with everything working again. Had to upgrade to IPA 4.6.6. It worked 
with 
Can you provide the exact steps that you ran? Performing a data-only 
backup does not save the configuration files and I would like to check 
how the new server was setup.

Sure. Backup was done with `ipa-backup --data --online`

The new server was a fresh CentOS install. Here the steps i did:
```
yum update -y
# reboot

yum install ipa-server -y
ipa-server-install  \
  --ds-password {{ipa_dm_pw}} \
  --admin-password {{ipa_admin_pw}} \
  --realm {{ceg_realm}} \
  --hostname {{inventory_hostname}}.{{ceg_domain}} \
  --domain {{ceg_domain}} \
  --mkhomedir \
  --unattended

ipa-restore --data --backend=userRoot
systemctl stop sssd
find /var/lib/sss/ ! -type d | xargs rm -f
systemctl start sssd
# reboot
```

I should mention that the `ipa ...` commands do not work on the server a 
have also tried on of the clients (unmodified) but it does not accept 
the SSL cert (probably because it is different now).


Best Regards
Lorenz
___
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

[Freeipa-users] Re: Looking for help to get my IPA server running again

[Florence Blanc-Renaud via FreeIPA-users]

On 7/16/20 11:02 AM, Lorenz Braun via FreeIPA-users wrote:

Hi there,

i have been running an IPA install (4.5.0) on a CentOS 7 server for 
quite a while and had some problems with it. Eventually everything got 
worse and now it is not really usable anymore.


It started with someone accidentally shutting down the server. From that 
point one of the services did not run anymore. Not 100% sure but i think 
it was pki-tomcat. I "fixed" it temporarily by using the 
'--ignore-service-failures' flag with ipactl. Everything seemed fine 
until about one or two weeks ago.

Hi,
this type of failure can happen when the certificates expire. You can 
check if that's the case using "getcert list" and look at the "status:" 
values that should be MONITORING and the "expires:" date.


Although the manual repair procedure can be quite long, it's possible to 
fix this type of issue. See [1] for instructions.


Some Clients could sometimes not get kerberos tickets. I couldn't quite 
figure out why.


I used 'ipa-backup --data' in hopes of restoring it on a fresh OS with 
everything working again. Had to upgrade to IPA 4.6.6. It worked with 
Can you provide the exact steps that you ran? Performing a data-only 
backup does not save the configuration files and I would like to check 
how the new server was setup.


flo

[1] https://access.redhat.com/solutions/3357261

'ipa-restore --data --backend=userRoot'. 'kinit' works, but i can't use 
any 'ipa ...' commands. Here an example:


```
[root@ipa01 ~]# ipa -v user-find --all
ipa: INFO: trying https://ipa01.example.com/ipa/json
ipa: INFO: [try 1]: Forwarding 'schema' to json server 
'https://ipa01.example.com/ipa/json'

ipa: ERROR: No valid Negotiate header in server response
```

/var/log/httpd/error_log:
```
[Thu Jul 16 10:40:27.007724 2020] [auth_gssapi:error] [pid 2210] [client 
xx.xx.xx.1:40920] GSS ERROR gss_acquire_cred[_from]() failed to get 
server creds: [Unspecified GSS failure.  Minor code may provide more 
information ( SPNEGO cannot find mechanisms to negotiate)], referer: 
https://ipa01.example.com/ipa/xml

```

/var/log/messages:
```
[...]
Jul 16 10:40:26 ipa01 gssproxy: [CID 14][2020/07/16 08:40:26]: 
gp_rpc_execute: executing 6 (GSSX_ACQUIRE_CRED) for service "ipa-httpd", 
euid: 48,socket: (null)
Jul 16 10:40:26 ipa01 gssproxy: GSSX_ARG_ACQUIRE_CRED( call_ctx: { "" [ 
] } input_cred_handle:  add_cred: 0 desired_name:  time_req: 
4294967295 desired_mechs: { { 1 2 840 113554 1 2 2 } } cred_usage: BOTH 
initiator_time_req: 0 acceptor_time_req: 0 )
Jul 16 10:40:26 ipa01 gssproxy: gssproxy[2408]: (OID: { 1 2 840 113554 1 
2 2 }) Unspecified GSS failure.  Minor code may provide more 
information, Preauthentication failed
Jul 16 10:40:26 ipa01 gssproxy: GSSX_RES_ACQUIRE_CRED( status: { 851968 
{ 1 2 840 113554 1 2 2 } 2529638936 "Unspecified GSS failure.  Minor 
code may provide more information" "Preauthentication failed" [  ] } 
output_cred_handle:  )
Jul 16 10:40:26 ipa01 gssproxy: [CID 14][2020/07/16 08:40:26]: 
gp_rpc_execute: executing 6 (GSSX_ACQUIRE_CRED) for service "ipa-httpd", 
euid: 48,socket: (null)
Jul 16 10:40:26 ipa01 gssproxy: GSSX_ARG_ACQUIRE_CRED( call_ctx: { "" [ 
] } input_cred_handle:  add_cred: 0 desired_name:  time_req: 
4294967295 desired_mechs: { { 1 2 840 113554 1 2 2 } } cred_usage: BOTH 
initiator_time_req: 0 acceptor_time_req: 0 )
Jul 16 10:40:27 ipa01 gssproxy: gssproxy[2408]: (OID: { 1 2 840 113554 1 
2 2 }) Unspecified GSS failure.  Minor code may provide more 
information, Preauthentication failed
Jul 16 10:40:27 ipa01 gssproxy: GSSX_RES_ACQUIRE_CRED( status: { 851968 
{ 1 2 840 113554 1 2 2 } 2529638936 "Unspecified GSS failure.  Minor 
code may provide more information" "Preauthentication failed" [  ] } 
output_cred_handle:  )
Jul 16 10:40:34 ipa01 [sssd[ldap_child[15047]]]: Failed to initialize 
credentials using keytab [MEMORY:/etc/krb5.keytab]: Preauthentication 
failed. Unable to create GSSAPI-encrypted LDAP connection.

[...]
```

Does anyone know how to fix this or debug it further? I still have a 
snapshot of the old ipa machine if that helps.
I am also thinking about just backing up the user database (usernames 
and passwords, everything else is nice but not required) and using a 
fresh install with just the user data. I how much different this would 
be from what i have done now to be honest.
Re-installing the clients is not much work for me, because it is well 
automated and there are few clients anyway.


I hope this was not too long and convoluted. I'll be glad about any help.

Best regards
Lorenz
___
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: 

[Freeipa-users] Re: LDAP conflicts and ldapsubentry

[Florence Blanc-Renaud via FreeIPA-users]

On 7/16/20 11:36 AM, David Harvey via FreeIPA-users wrote:
Hi again, just a gentle bump to keep this visible, any advice on it or 
additional info I can provide?


On Tue, 14 Jul 2020 at 19:29, David Harvey > wrote:


Dear list,

I noted from TFM


that conflicting values have ldapSubEntry and nsds5ReplConflict
attributes, however it only mentioned removing the latter. Should we
in fact remove ldapsubentry as well when resolving these conflicts?

For the two conflicts I had, I noted:
1. cn: ipservices was identical apart from the aforementioned
attributes.
*laregly resolved but ldapsubentry still in place taking the newer
version over old

No need to remove the ldapsubentry objectclass.



2. I had a subtly different "cn: System: Read POSIX details of SMB
services". Conflicting entries (ipaPermDefaultAttr: uid vs
ipaPermDefaultAttr: uidnumber) which I assume to be a schema change
during upgrade that borked somehow?
* I haven't actioned this one yet given the discrepancy.

I have the following entry on ipa 4.8.4:

dn: cn=System: Read POSIX details of SMB 
services,cn=permissions,cn=pbac,$BASEDN

cn: System: Read POSIX details of SMB services
ipaPermissionType: SYSTEM
ipaPermissionType: V2
ipaPermissionType: MANAGED
objectClass: top
objectClass: groupofnames
objectClass: ipapermission
objectClass: ipapermissionv2
ipaPermTargetFilter: (objectclass=ipaservice)
ipaPermLocation: cn=services,cn=accounts,$BASEN
ipaPermBindRuleType: all
ipaPermRight: compare
ipaPermRight: search
ipaPermRight: read
ipaPermDefaultAttr: gidnumber
ipaPermDefaultAttr: ipantsecurityidentifier
ipaPermDefaultAttr: loginshell
ipaPermDefaultAttr: gecos
ipaPermDefaultAttr: objectclass
ipaPermDefaultAttr: uid
ipaPermDefaultAttr: cn
ipaPermDefaultAttr: homedirectory
ipaPermDefaultAttr: uidnumber

=> To solve the conflict, you need to keep both uid and uidnumber in the 
resulting entry.


This permission was added in ipa 4.8.0 but never modified after that 
version. The conflict probably got created because of parallel upgrade 
of the IPA servers. The recommendation when upgrading a topology is to 
run sequential updates, please see [1]:

- update server 1
- wait a few minutes for replication to sync the changes
- update server 2
- wait a few minutes for replication to sync the changes
...

HTH,
flo

[1] 
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/linux_domain_identity_authentication_and_policy_guide/updating-migrating#update-ipa-yum




Recently upgraded packages in centos which took us from 4.7.6 (IIRC)
to  4.8.4.

Thanks as ever,

David


___
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


___
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

[Freeipa-users] Re: LDAP conflicts and ldapsubentry

[David Harvey via FreeIPA-users]

Hi again, just a gentle bump to keep this visible, any advice on it or
additional info I can provide?

On Tue, 14 Jul 2020 at 19:29, David Harvey 
wrote:

> Dear list,
>
> I noted from TFM
> 
> that conflicting values have ldapSubEntry and nsds5ReplConflict attributes,
> however it only mentioned removing the latter. Should we in fact remove
> ldapsubentry as well when resolving these conflicts?
>
> For the two conflicts I had, I noted:
> 1. cn: ipservices was identical apart from the aforementioned attributes.
> *laregly resolved but ldapsubentry still in place taking the newer version
> over old
>
> 2. I had a subtly different "cn: System: Read POSIX details of SMB
> services". Conflicting entries (ipaPermDefaultAttr: uid vs
> ipaPermDefaultAttr: uidnumber) which I assume to be a schema change during
> upgrade that borked somehow?
> * I haven't actioned this one yet given the discrepancy.
>
> Recently upgraded packages in centos which took us from 4.7.6 (IIRC) to
> 4.8.4.
>
> Thanks as ever,
>
> David
>
___
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

[Freeipa-users] Looking for help to get my IPA server running again

[Lorenz Braun via FreeIPA-users]

Hi there,

i have been running an IPA install (4.5.0) on a CentOS 7 server for 
quite a while and had some problems with it. Eventually everything got 
worse and now it is not really usable anymore.


It started with someone accidentally shutting down the server. From that 
point one of the services did not run anymore. Not 100% sure but i think 
it was pki-tomcat. I "fixed" it temporarily by using the 
'--ignore-service-failures' flag with ipactl. Everything seemed fine 
until about one or two weeks ago.
Some Clients could sometimes not get kerberos tickets. I couldn't quite 
figure out why.


I used 'ipa-backup --data' in hopes of restoring it on a fresh OS with 
everything working again. Had to upgrade to IPA 4.6.6. It worked with 
'ipa-restore --data --backend=userRoot'. 'kinit' works, but i can't use 
any 'ipa ...' commands. Here an example:


```
[root@ipa01 ~]# ipa -v user-find --all
ipa: INFO: trying https://ipa01.example.com/ipa/json
ipa: INFO: [try 1]: Forwarding 'schema' to json server 
'https://ipa01.example.com/ipa/json'

ipa: ERROR: No valid Negotiate header in server response
```

/var/log/httpd/error_log:
```
[Thu Jul 16 10:40:27.007724 2020] [auth_gssapi:error] [pid 2210] [client 
xx.xx.xx.1:40920] GSS ERROR gss_acquire_cred[_from]() failed to get 
server creds: [Unspecified GSS failure.  Minor code may provide more 
information ( SPNEGO cannot find mechanisms to negotiate)], referer: 
https://ipa01.example.com/ipa/xml

```

/var/log/messages:
```
[...]
Jul 16 10:40:26 ipa01 gssproxy: [CID 14][2020/07/16 08:40:26]: 
gp_rpc_execute: executing 6 (GSSX_ACQUIRE_CRED) for service "ipa-httpd", 
euid: 48,socket: (null)
Jul 16 10:40:26 ipa01 gssproxy: GSSX_ARG_ACQUIRE_CRED( call_ctx: { "" [  
] } input_cred_handle:  add_cred: 0 desired_name:  time_req: 
4294967295 desired_mechs: { { 1 2 840 113554 1 2 2 } } cred_usage: BOTH 
initiator_time_req: 0 acceptor_time_req: 0 )
Jul 16 10:40:26 ipa01 gssproxy: gssproxy[2408]: (OID: { 1 2 840 113554 1 
2 2 }) Unspecified GSS failure.  Minor code may provide more 
information, Preauthentication failed
Jul 16 10:40:26 ipa01 gssproxy: GSSX_RES_ACQUIRE_CRED( status: { 851968 
{ 1 2 840 113554 1 2 2 } 2529638936 "Unspecified GSS failure.  Minor 
code may provide more information" "Preauthentication failed" [  ] } 
output_cred_handle:  )
Jul 16 10:40:26 ipa01 gssproxy: [CID 14][2020/07/16 08:40:26]: 
gp_rpc_execute: executing 6 (GSSX_ACQUIRE_CRED) for service "ipa-httpd", 
euid: 48,socket: (null)
Jul 16 10:40:26 ipa01 gssproxy: GSSX_ARG_ACQUIRE_CRED( call_ctx: { "" [  
] } input_cred_handle:  add_cred: 0 desired_name:  time_req: 
4294967295 desired_mechs: { { 1 2 840 113554 1 2 2 } } cred_usage: BOTH 
initiator_time_req: 0 acceptor_time_req: 0 )
Jul 16 10:40:27 ipa01 gssproxy: gssproxy[2408]: (OID: { 1 2 840 113554 1 
2 2 }) Unspecified GSS failure.  Minor code may provide more 
information, Preauthentication failed
Jul 16 10:40:27 ipa01 gssproxy: GSSX_RES_ACQUIRE_CRED( status: { 851968 
{ 1 2 840 113554 1 2 2 } 2529638936 "Unspecified GSS failure.  Minor 
code may provide more information" "Preauthentication failed" [  ] } 
output_cred_handle:  )
Jul 16 10:40:34 ipa01 [sssd[ldap_child[15047]]]: Failed to initialize 
credentials using keytab [MEMORY:/etc/krb5.keytab]: Preauthentication 
failed. Unable to create GSSAPI-encrypted LDAP connection.

[...]
```

Does anyone know how to fix this or debug it further? I still have a 
snapshot of the old ipa machine if that helps.
I am also thinking about just backing up the user database (usernames 
and passwords, everything else is nice but not required) and using a 
fresh install with just the user data. I how much different this would 
be from what i have done now to be honest.
Re-installing the clients is not much work for me, because it is well 
automated and there are few clients anyway.


I hope this was not too long and convoluted. I'll be glad about any help.

Best regards
Lorenz
___
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