date:20170111

Re: [Freeipa-users] Asking for help with crashed freeIPA istance

2017-01-11 Thread Daniel Schimpfoessl

Flo,

these are all the errors found:
grep 'RESULT err=' access | perl -pe 's/.*(RESULT\s+err=\d+).*/$1/g' | sort
-n | uniq -c | sort -n
  2 RESULT err=6
 95 RESULT err=32
200 RESULT err=14
   2105 RESULT err=0


2017-01-05 8:10 GMT-06:00 Florence Blanc-Renaud :

> On 01/04/2017 07:24 PM, Daniel Schimpfoessl wrote:
>
>> From the logs:
>> /var/log/dirsrv/slapd-DOMAIN-COM/errors
>> ... a few warnings about cache size, NSACLPLugin and schema-compat-plugin
>> [04/Jan/2017:12:14:21.392642021 -0600] slapd started.  Listening on All
>> Interfaces port 389 for LDAP requests
>>
>> /var/log/dirsrv/slapd-DOMAIN-COM/access
>> ... lots of entries, not sure what to look for some lines contain RESULT
>> with err!=0
>> [04/Jan/2017:12:18:01.753400307 -0600] conn=5 op=243 RESULT err=32
>> tag=101 nentries=0 etime=0
>> [04/Jan/2017:12:18:01.786928085 -0600] conn=44 op=1 RESULT err=14 tag=97
>> nentries=0 etime=0, SASL bind in progress
>>
>> Hi Daniel,
>
> are there any RESULT err=48 that could correspond to the error seen on pki
> logs?
>
> Flo
>
> /var/log/dirsrv/slapd-DOMAIN-COM/errors
>> [04/Jan/2017:12:19:25.566022098 -0600] slapd shutting down - signaling
>> operation threads - op stack size 5 max work q size 2 max work q stack
>> size 2
>> [04/Jan/2017:12:19:25.572566622 -0600] slapd shutting down - closing
>> down internal subsystems and plugins
>>
>>
>> 2017-01-04 8:38 GMT-06:00 Daniel Schimpfoessl > >:
>>
>> Do you have a list of all log files involved in IPA?
>> Would be good to consolidate them into ELK for analysis.
>>
>> 2017-01-04 2:48 GMT-06:00 Florence Blanc-Renaud > >:
>>
>>
>> On 01/02/2017 07:24 PM, Daniel Schimpfoessl wrote:
>>
>> Thanks for your reply.
>>
>> This was the initial error I asked for help a while ago and
>> did not get
>> resolved. Further digging showed the recent errors.
>> The service was running (using ipactl start --force) and
>> only after a
>> restart I am getting a stack trace for two primary messages:
>>
>> Could not connect to LDAP server host wwgwho01.webwim.com
>> 
>>  port 636 Error
>> netscape.ldap.LDAPException:
>> Authentication failed (48)
>> ...
>>
>> Internal Database Error encountered: Could not connect to
>> LDAP server
>> host wwgwho01.webwim.com 
>>  port 636 Error
>> netscape.ldap.LDAPException: Authentication failed (48)
>> ...
>>
>> and finally:
>> [02/Jan/2017:12:20:34][localhost-startStop-1]:
>> CMSEngine.shutdown()
>>
>>
>> 2017-01-02 3:45 GMT-06:00 Florence Blanc-Renaud
>> 
>> >>:
>>
>> systemctl start pki-tomcatd@pki-tomcat.service
>>
>>
>>
>> Hi Daniel,
>>
>> the next step would be to understand the root cause of this
>> "Authentication failed (48)" error. Note the exact time of this
>> log and look for a corresponding log in the LDAP server logs
>> (/var/log/dirsrv/slapd-DOMAIN-COM/access), probably a failing
>> BIND with err=48. This may help diagnose the issue (if we can
>> see which certificate is used for the bind or if there is a
>> specific error message).
>>
>> For the record, a successful bind over SSL would produce this
>> type of log where we can see the certificate subject and the
>> user mapped to this certificate:
>> [...] conn=47 fd=84 slot=84 SSL connection from 10.34.58.150 to
>> 10.34.58.150
>> [...] conn=47 TLS1.2 128-bit AES; client CN=CA
>> Subsystem,O=DOMAIN.COM ; issuer
>> CN=Certificate Authority,O=DOMAIN.COM 
>> [...] conn=47 TLS1.2 client bound as
>> uid=pkidbuser,ou=people,o=ipaca
>> [...] conn=47 op=0 BIND dn="" method=sasl version=3 mech=EXTERNAL
>> [...] conn=47 op=0 RESULT err=0 tag=97 nentries=0 etime=0
>> dn="uid=pkidbuser,ou=people,o=ipaca"
>>
>> Flo
>>
>>
>>
>>
>
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] pki-tomcat failure

2017-01-11 Thread Bob Hinton

On 11/01/2017 13:55, Petr Vobornik wrote:
> On 01/10/2017 09:31 PM, Bob Hinton wrote:
>> Hi,
>>
>> The pki-tomcatd services on our IPA servers seem to have stopped working.
>>
>> This seems to be related to the expiry of several certificates -
>>
>> [root@ipa001 ~]# getcert list | more
>> Number of certificates and requests being tracked: 8.
>> Request ID '20161230150048':
>> status: MONITORING
>> stuck: no
>> key pair storage:
>> type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='auditSigningCert
>> cert-pki-ca',token='NSS Certificate DB',pin set
>> certificate:
>> type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='auditSigningCert
>> cert-pki-ca',token='NSS Certificate DB'
>> CA: dogtag-ipa-ca-renew-agent
>> issuer: CN=Certificate Authority,O=LOCAL.COM
>> subject: CN=CA Audit,O=LOCAL.COM
>> expires: 2017-01-09 08:21:45 UTC
>> key usage: digitalSignature,nonRepudiation
>> pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad
>> post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert
>> "auditSigningCert cert-pki-ca"
>> track: yes
>> auto-renew: yes
>> Request ID '20161230150049':
>> status: MONITORING
>> stuck: no
>> key pair storage:
>> type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='ocspSigningCert
>> cert-pki-ca',token='NSS Certificate DB',pin set
>> certificate:
>> type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='ocspSigningCert
>> cert-pki-ca',token='NSS Certificate DB'
>> CA: dogtag-ipa-ca-renew-agent
>> issuer: CN=Certificate Authority,O=LOCAL.COM
>> subject: CN=OCSP Subsystem,O=LOCAL.COM
>> expires: 2017-01-09 08:21:45 UTC
>> key usage: digitalSignature,nonRepudiation,keyCertSign,cRLSign
>> eku: id-kp-OCSPSigning
>> pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad
>> post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert
>> "ocspSigningCert cert-pki-ca"
>> track: yes
>> auto-renew: yes
>>
>> These were originally in CA_WORKING state, but I moved the clock back
>> and restarted certmonger to try to renew them.
>
> Certs above have:
>expires: 2017-01-09 08:21:45 UTC
>
> But log has 10/Jan so the log is from the time when certs are expired.
>
> Move time back when all certs reported by `getcert list` are valid.
> Restart IPA. Resubmit all certs which are about to expire. Move time back.
>
Hi Petr,

I had already tried moving the clock back, but unfortunately tomcat-pki
still wouldn't start. I had to temporarily configure it to connect to
LDAP using BasicAuth, as suggested by Adam Tkac. With this done and the
time moved back tomcat-pki started OK and restarting certmonger made it
renew all the certs.

Presumably something was already broken and so certmonger didn't renew
them in the first place.

Thanks

Bob
>>
>> /var/log/pki/pki-tomcat/ca/debug contains
>>
>> [10/Jan/2017:18:35:37][localhost-startStop-1]: makeConnection:
>> errorIfDown true
>> [10/Jan/2017:18:35:37][localhost-startStop-1]:
>> SSLClientCertificateSelectionCB: Setting desired cert nickname to:
>> subsystemCert cert-pki-ca
>> [10/Jan/2017:18:35:37][localhost-startStop-1]: LdapJssSSLSocket: set
>> client auth cert nickname subsystemCert cert-pki-ca
>> [10/Jan/2017:18:35:37][localhost-startStop-1]:
>> SSLClientCertificatSelectionCB: Entering!
>> [10/Jan/2017:18:35:37][localhost-startStop-1]: Candidate cert:
>> caSigningCert cert-pki-ca
>> [10/Jan/2017:18:35:37][localhost-startStop-1]: Candidate cert:
>> Server-Cert cert-pki-ca
>> [10/Jan/2017:18:35:37][localhost-startStop-1]:
>> SSLClientCertificateSelectionCB: returning: null
>> [10/Jan/2017:18:35:37][localhost-startStop-1]: SSL handshake happened
>> Could not connect to LDAP server host ipa001.mgmt.local.com port 636
>> Error netscape.ldap.LDAPException: Authentication failed (48)
>> at
>> com.netscape.cmscore.ldapconn.LdapBoundConnFactory.makeConnection(LdapBoundConnFactory.java:205)
>> at
>> com.netscape.cmscore.ldapconn.LdapBoundConnFactory.init(LdapBoundConnFactory.java:166)
>> at
>> com.netscape.cmscore.ldapconn.LdapBoundConnFactory.init(LdapBoundConnFactory.java:130)
>> at com.netscape.cmscore.dbs.DBSubsystem.init(DBSubsystem.java:654)
>> at
>> com.netscape.cmscore.apps.CMSEngine.initSubsystem(CMSEngine.java:1169)
>> at
>> com.netscape.cmscore.apps.CMSEngine.initSubsystems(CMSEngine.java:1075)
>> at com.netscape.cmscore.apps.CMSEngine.init(CMSEngine.java:571)
>> at com.netscape.certsrv.apps.CMS.init(CMS.java:187)
>> at com.netscape.certsrv.apps.CMS.start(CMS.java:1616)
>> at
>> com.netscape.cms.servlet.base.CMSStartServlet.init(CMSStartServlet.java:114)
>> at javax.servlet.GenericServlet.init(GenericServlet.java:158)
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> at
>>

Re: [Freeipa-users] CA crt renew -- encoding mismatch

2017-01-11 Thread Jan Orel

To sum up, our problem was we did not install new CA crt on all replicas,
which should be probably done using "ipa-certupdate", but we missed that in
the documentation.

Regarding the certificates encoding, we noticed that after the upgrade v3
-> v4 IPA issues certificates in UTF8STRING and as long as our CA crt was
still PRINTABLESTRING, it created miss-matched certificates. This could be
fixed by the CA crt renew.

J.


2017-01-04 16:46 GMT+01:00 Jan Orel :

> Hello,
>
> recently we renewed our CA crt. Later we noticed the new CA certificate
> uses different encoding in Issuer and Subject:
>
> subject=
> organizationName  = UTF8STRING:INTGDC.COM
> commonName= UTF8STRING:Certificate Authority
> issuer=
> organizationName  = PRINTABLESTRING:INTGDC.COM
> commonName= PRINTABLESTRING:Certificate Authority
>
> The former CA certificate is PRINTABLESTRING in both fields, as well as
> all the older certs.
>
> Since the renewal we have issues with trusting newly issued certificates,
> which also have different encoding in subject and issuer.
>
> What should be the default (correct) encoding for the certificates?
>
> According to the: http://www.freeipa.org/page/Troubleshooting seems it
> should be UTF8
>
> but from the certmonger: https://git.fedorahosted.org/cgit/
> certmonger.git/commit/?id=e6ecd5d8df3413a9717c57ee7fb8702ece23afd6
>
> seems PRINTABLESTRING is used.
>
> How to fix? Do we need to re-new the CA certificate once again?
>
> Thank you
> Jan Orel
>
> We run:
> ipa-server-4.2.0-15.0.1.el7.centos.19.x86_64
> certmonger-0.78.4-1.el7.x86_64
> nuxwdog-1.0.3-4.el7_2.x86_64
>
-- 
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] secondary out of sync on DNS again [solved]

2017-01-11 Thread Outback Dingo

working through it slowly now... :)


On Wed, Jan 11, 2017 at 11:22 AM, Martin Basti  wrote:
> Have you tried the ldapsearch from the guide I sent you?
>
>
>
> On 11.01.2017 17:03, Outback Dingo wrote:
>>
>> I am still seeing this, and the same message about LDAP
>>
>>   ./ipa_check_consistency -H
>> ipa2.optimcloud.com -d OPTIMCLOUD.COM
>> Directory Manager password:
>> FreeIPA servers:ipa2STATE
>> =
>> Active Users1   OK
>> Stage Users 0   OK
>> Preserved Users 0   OK
>> User Groups 4   OK
>> Hosts   8   OK
>> Host Groups 2   OK
>> HBAC Rules  1   OK
>> SUDO Rules  0   OK
>> DNS Zones   26  OK
>> LDAP Conflicts  YES FAIL
>> Ghost Replicas  NO  OK
>> Anonymous BIND  YES OK
>> Replication Status  ipa 0
>> Jan 11 11:02:06 ipa2.optimcloud.com named-pkcs11[2516]: LDAP data for
>> instance 'ipa' are being synchronized, please ignore message 'all
>> zones loaded'
>> Jan 11 11:02:06 ipa2.optimcloud.com named-pkcs11[2516]: bug in
>> dn_to_dnsname(): multi-valued RDNs are not supported
>> Jan 11 11:02:06 ipa2.optimcloud.com named-pkcs11[2516]: failed to
>> convert DN
>> 'idnsname=store+nsuniqueid=44fbbd0e-d80a11e6-ad7498e5-1ca0119b,idnsname=optimcloud.com.,cn=dns,dc=optimcloud,dc=com'
>> to DNS name: not implemented
>> Jan 11 11:02:06 ipa2.optimcloud.com named-pkcs11[2516]:
>> ldap_sync_search_entry failed: not implemented
>> Jan 11 11:02:07 ipa2.optimcloud.com named-pkcs11[2516]: zone
>> 150.217.162.in-addr.arpa/IN: loaded serial 1484150526
>> Jan 11 11:02:07 ipa2.optimcloud.com named-pkcs11[2516]: zone
>> optimvoice.co/IN: loaded serial 1484150526
>> Jan 11 11:02:07 ipa2.optimcloud.com named-pkcs11[2516]: zone
>> optimcloud.com/IN: loaded serial 1484150526
>>
>> On Wed, Jan 11, 2017 at 10:56 AM, Martin Basti  wrote:
>>>
>>> Great :)
>>>
>>>
>>> On 11.01.2017 16:52, Outback Dingo wrote:

 damn... DMARC record removed, now synced

 On Wed, Jan 11, 2017 at 10:33 AM, Martin Basti 
 wrote:
>
> Please try to create a new test user if it is replicated to other
> replicas.
>
>
> I see repl. conflicts please try to investigate them, it may cause a
> missing
> zone
>
>
>
> https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html
>
>
> could you check what do you have in journalctl -u named-pkcs11 on
> replica
> with missing entries?
>
> Martin
>
>
> On 11.01.2017 16:27, Outback Dingo wrote:
>>
>> Not realliy, not like last time but
>> [root@ipa2 ~]# cd ipa_check_consistency/
>> [root@ipa2 ipa_check_consistency]# ./ipa_check_consistency -H
>> ipa2.optimcloud.com -d OPTIMCLOUD.COM
>> Directory Manager password:
>> FreeIPA servers:ipa2STATE
>> =
>> Active Users1   OK
>> Stage Users 0   OK
>> Preserved Users 0   OK
>> User Groups 4   OK
>> Hosts   8   OK
>> Host Groups 2   OK
>> HBAC Rules  1   OK
>> SUDO Rules  0   OK
>> DNS Zones   26  OK
>> LDAP Conflicts  YES FAIL
>> Ghost Replicas  NO  OK
>> Anonymous BIND  YES OK
>> Replication Status  ipa 0
>>
>>
>>
>> [07/Jan/2017:23:59:33.034771024 -0500] slapd shutting down - signaling
>> operation threads - op stack size 1 max work q size 3 max work q stack
>> size 3
>> [07/Jan/2017:23:59:33.080148204 -0500] slapd shutting down - waiting
>> for 26 threads to terminate
>> [08/Jan/2017:00:01:43.342292791 -0500] SSL alert: Sending pin request
>> to SVRCore. You may need to run systemd-tty-ask-password-agent to
>> provide the password.
>> [08/Jan/2017:00:01:43.348739255 -0500] SSL alert: Security
>> Initialization: Enabling default cipher set.
>> [08/Jan/2017:00:01:43.349917267 -0500] SSL alert: Configured NSS
>> Ciphers
>> [08/Jan/2017:00:01:43.350819261 -0500] SSL alert:
>> TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384: enabled
>> [08/Jan/2017:00:01:43.352925341 -0500] SSL alert:
>> TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA: enabled
>> [08/Jan/2017:00:01:43.354043098 -0500] SSL alert:
>> TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256: enabled
>> [08/Jan/2017:00:01:43.354944795 -0500] SSL alert:
>> TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA: enabled
>> [08/Jan/2017:00:01:43.355929413 -0500] SSL alert:
>> TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384: enabled
>> [08/Jan/2017:00:01:43.356793063 -0500] SSL alert:
>> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA: enabled
>> [08/Jan/2017:00:01:43.357650823 -0500] SSL alert:
>>

Re: [Freeipa-users] secondary out of sync on DNS again [solved]

2017-01-11 Thread Martin Basti


Have you tried the ldapsearch from the guide I sent you?


On 11.01.2017 17:03, Outback Dingo wrote:

I am still seeing this, and the same message about LDAP

  ./ipa_check_consistency -H
ipa2.optimcloud.com -d OPTIMCLOUD.COM
Directory Manager password:
FreeIPA servers:ipa2STATE
=
Active Users1   OK
Stage Users 0   OK
Preserved Users 0   OK
User Groups 4   OK
Hosts   8   OK
Host Groups 2   OK
HBAC Rules  1   OK
SUDO Rules  0   OK
DNS Zones   26  OK
LDAP Conflicts  YES FAIL
Ghost Replicas  NO  OK
Anonymous BIND  YES OK
Replication Status  ipa 0
Jan 11 11:02:06 ipa2.optimcloud.com named-pkcs11[2516]: LDAP data for
instance 'ipa' are being synchronized, please ignore message 'all
zones loaded'
Jan 11 11:02:06 ipa2.optimcloud.com named-pkcs11[2516]: bug in
dn_to_dnsname(): multi-valued RDNs are not supported
Jan 11 11:02:06 ipa2.optimcloud.com named-pkcs11[2516]: failed to
convert DN 
'idnsname=store+nsuniqueid=44fbbd0e-d80a11e6-ad7498e5-1ca0119b,idnsname=optimcloud.com.,cn=dns,dc=optimcloud,dc=com'
to DNS name: not implemented
Jan 11 11:02:06 ipa2.optimcloud.com named-pkcs11[2516]:
ldap_sync_search_entry failed: not implemented
Jan 11 11:02:07 ipa2.optimcloud.com named-pkcs11[2516]: zone
150.217.162.in-addr.arpa/IN: loaded serial 1484150526
Jan 11 11:02:07 ipa2.optimcloud.com named-pkcs11[2516]: zone
optimvoice.co/IN: loaded serial 1484150526
Jan 11 11:02:07 ipa2.optimcloud.com named-pkcs11[2516]: zone
optimcloud.com/IN: loaded serial 1484150526

On Wed, Jan 11, 2017 at 10:56 AM, Martin Basti  wrote:

Great :)


On 11.01.2017 16:52, Outback Dingo wrote:

damn... DMARC record removed, now synced

On Wed, Jan 11, 2017 at 10:33 AM, Martin Basti  wrote:

Please try to create a new test user if it is replicated to other
replicas.


I see repl. conflicts please try to investigate them, it may cause a
missing
zone


https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html


could you check what do you have in journalctl -u named-pkcs11 on replica
with missing entries?

Martin


On 11.01.2017 16:27, Outback Dingo wrote:

Not realliy, not like last time but
[root@ipa2 ~]# cd ipa_check_consistency/
[root@ipa2 ipa_check_consistency]# ./ipa_check_consistency -H
ipa2.optimcloud.com -d OPTIMCLOUD.COM
Directory Manager password:
FreeIPA servers:ipa2STATE
=
Active Users1   OK
Stage Users 0   OK
Preserved Users 0   OK
User Groups 4   OK
Hosts   8   OK
Host Groups 2   OK
HBAC Rules  1   OK
SUDO Rules  0   OK
DNS Zones   26  OK
LDAP Conflicts  YES FAIL
Ghost Replicas  NO  OK
Anonymous BIND  YES OK
Replication Status  ipa 0



[07/Jan/2017:23:59:33.034771024 -0500] slapd shutting down - signaling
operation threads - op stack size 1 max work q size 3 max work q stack
size 3
[07/Jan/2017:23:59:33.080148204 -0500] slapd shutting down - waiting
for 26 threads to terminate
[08/Jan/2017:00:01:43.342292791 -0500] SSL alert: Sending pin request
to SVRCore. You may need to run systemd-tty-ask-password-agent to
provide the password.
[08/Jan/2017:00:01:43.348739255 -0500] SSL alert: Security
Initialization: Enabling default cipher set.
[08/Jan/2017:00:01:43.349917267 -0500] SSL alert: Configured NSS Ciphers
[08/Jan/2017:00:01:43.350819261 -0500] SSL alert:
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384: enabled
[08/Jan/2017:00:01:43.352925341 -0500] SSL alert:
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA: enabled
[08/Jan/2017:00:01:43.354043098 -0500] SSL alert:
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256: enabled
[08/Jan/2017:00:01:43.354944795 -0500] SSL alert:
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA: enabled
[08/Jan/2017:00:01:43.355929413 -0500] SSL alert:
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384: enabled
[08/Jan/2017:00:01:43.356793063 -0500] SSL alert:
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA: enabled
[08/Jan/2017:00:01:43.357650823 -0500] SSL alert:
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256: enabled
[08/Jan/2017:00:01:43.358754848 -0500] SSL alert:
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA: enabled
[08/Jan/2017:00:01:43.359655681 -0500] SSL alert:
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384: enabled
[08/Jan/2017:00:01:43.360741758 -0500] SSL alert:
TLS_DHE_RSA_WITH_AES_256_CBC_SHA: enabled
[08/Jan/2017:00:01:43.361650705 -0500] SSL alert:
TLS_DHE_DSS_WITH_AES_256_CBC_SHA: enabled
[08/Jan/2017:00:01:43.362718051 -0500] SSL alert:
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256: enabled
[08/Jan/2017:00:01:43.363594439 -0500] SSL alert:
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256: enabled
[08/Jan/2017:00:01:43.365599343 -0500] SSL alert:
TLS_DHE_RSA_WITH_AES_128_CBC_SHA: enabled
[08/Jan/2017:00:01:43.366719360 -0500]

Re: [Freeipa-users] secondary out of sync on DNS again [solved]

2017-01-11 Thread Martin Basti



Great :)


On 11.01.2017 16:52, Outback Dingo wrote:

damn... DMARC record removed, now synced

On Wed, Jan 11, 2017 at 10:33 AM, Martin Basti  wrote:

Please try to create a new test user if it is replicated to other replicas.


I see repl. conflicts please try to investigate them, it may cause a missing
zone

https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html


could you check what do you have in journalctl -u named-pkcs11 on replica
with missing entries?

Martin


On 11.01.2017 16:27, Outback Dingo wrote:

Not realliy, not like last time but
[root@ipa2 ~]# cd ipa_check_consistency/
[root@ipa2 ipa_check_consistency]# ./ipa_check_consistency -H
ipa2.optimcloud.com -d OPTIMCLOUD.COM
Directory Manager password:
FreeIPA servers:ipa2STATE
=
Active Users1   OK
Stage Users 0   OK
Preserved Users 0   OK
User Groups 4   OK
Hosts   8   OK
Host Groups 2   OK
HBAC Rules  1   OK
SUDO Rules  0   OK
DNS Zones   26  OK
LDAP Conflicts  YES FAIL
Ghost Replicas  NO  OK
Anonymous BIND  YES OK
Replication Status  ipa 0



[07/Jan/2017:23:59:33.034771024 -0500] slapd shutting down - signaling
operation threads - op stack size 1 max work q size 3 max work q stack
size 3
[07/Jan/2017:23:59:33.080148204 -0500] slapd shutting down - waiting
for 26 threads to terminate
[08/Jan/2017:00:01:43.342292791 -0500] SSL alert: Sending pin request
to SVRCore. You may need to run systemd-tty-ask-password-agent to
provide the password.
[08/Jan/2017:00:01:43.348739255 -0500] SSL alert: Security
Initialization: Enabling default cipher set.
[08/Jan/2017:00:01:43.349917267 -0500] SSL alert: Configured NSS Ciphers
[08/Jan/2017:00:01:43.350819261 -0500] SSL alert:
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384: enabled
[08/Jan/2017:00:01:43.352925341 -0500] SSL alert:
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA: enabled
[08/Jan/2017:00:01:43.354043098 -0500] SSL alert:
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256: enabled
[08/Jan/2017:00:01:43.354944795 -0500] SSL alert:
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA: enabled
[08/Jan/2017:00:01:43.355929413 -0500] SSL alert:
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384: enabled
[08/Jan/2017:00:01:43.356793063 -0500] SSL alert:
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA: enabled
[08/Jan/2017:00:01:43.357650823 -0500] SSL alert:
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256: enabled
[08/Jan/2017:00:01:43.358754848 -0500] SSL alert:
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA: enabled
[08/Jan/2017:00:01:43.359655681 -0500] SSL alert:
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384: enabled
[08/Jan/2017:00:01:43.360741758 -0500] SSL alert:
TLS_DHE_RSA_WITH_AES_256_CBC_SHA: enabled
[08/Jan/2017:00:01:43.361650705 -0500] SSL alert:
TLS_DHE_DSS_WITH_AES_256_CBC_SHA: enabled
[08/Jan/2017:00:01:43.362718051 -0500] SSL alert:
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256: enabled
[08/Jan/2017:00:01:43.363594439 -0500] SSL alert:
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256: enabled
[08/Jan/2017:00:01:43.365599343 -0500] SSL alert:
TLS_DHE_RSA_WITH_AES_128_CBC_SHA: enabled
[08/Jan/2017:00:01:43.366719360 -0500] SSL alert:
TLS_DHE_DSS_WITH_AES_128_CBC_SHA: enabled
[08/Jan/2017:00:01:43.368835924 -0500] SSL alert:
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256: enabled
[08/Jan/2017:00:01:43.370913228 -0500] SSL alert:
TLS_RSA_WITH_AES_256_GCM_SHA384: enabled
[08/Jan/2017:00:01:43.372972786 -0500] SSL alert:
TLS_RSA_WITH_AES_256_CBC_SHA: enabled
[08/Jan/2017:00:01:43.375008604 -0500] SSL alert:
TLS_RSA_WITH_AES_256_CBC_SHA256: enabled
[08/Jan/2017:00:01:43.377060277 -0500] SSL alert:
TLS_RSA_WITH_AES_128_GCM_SHA256: enabled
[08/Jan/2017:00:01:43.379147161 -0500] SSL alert:
TLS_RSA_WITH_AES_128_CBC_SHA: enabled
[08/Jan/2017:00:01:43.381215466 -0500] SSL alert:
TLS_RSA_WITH_AES_128_CBC_SHA256: enabled
[08/Jan/2017:00:01:43.410666701 -0500] SSL Initialization - Configured
SSL version range: min: TLS1.0, max: TLS1.2
[08/Jan/2017:00:01:43.412541954 -0500] 389-Directory/1.3.5.10
B2016.341. starting up
[08/Jan/2017:00:01:43.432516181 -0500] default_mr_indexer_create:
warning - plugin [caseIgnoreIA5Match] does not handle
caseExactIA5Match
[08/Jan/2017:00:01:43.455710217 -0500] WARNING: changelog: entry cache
size 2097152 B is less than db size 4096000 B; We recommend to
increase the entry cache size nsslapd-cachememsize.
[08/Jan/2017:00:01:43.461914913 -0500] Detected Disorderly Shutdown
last time Directory Server was running, recovering database.
[08/Jan/2017:00:01:43.832287548 -0500] schema-compat-plugin -
scheduled schema-compat-plugin tree scan in about 5 seconds after the
server startup!
[08/Jan/2017:00:01:43.857795379 -0500] NSACLPlugin - The ACL target
cn=groups,cn=compat,dc=optimcloud,dc=com does not exist
[08/Jan/2017:00:01:43.859681661 -0500] NSACLPlugin - The ACL target

Re: [Freeipa-users] secondary out of sync on DNS again

2017-01-11 Thread Outback Dingo

Jan 11 08:45:56 ipa2.optimcloud.com named-pkcs11[2493]: automatic
empty zone: 123.100.IN-ADDR.ARPA
Jan 11 08:45:56 ipa2.optimcloud.com named-pkcs11[2493]: automatic
empty zone: 124.100.IN-ADDR.ARPA
Jan 11 08:45:56 ipa2.optimcloud.com named-pkcs11[2493]: automatic
empty zone: 125.100.IN-ADDR.ARPA
Jan 11 08:45:56 ipa2.optimcloud.com named-pkcs11[2493]: automatic
empty zone: 126.100.IN-ADDR.ARPA
Jan 11 08:45:56 ipa2.optimcloud.com named-pkcs11[2493]: automatic
empty zone: 127.100.IN-ADDR.ARPA
Jan 11 08:45:56 ipa2.optimcloud.com named-pkcs11[2493]: automatic
empty zone: 127.IN-ADDR.ARPA
Jan 11 08:45:56 ipa2.optimcloud.com named-pkcs11[2493]: automatic
empty zone: 254.169.IN-ADDR.ARPA
Jan 11 08:45:56 ipa2.optimcloud.com named-pkcs11[2493]: automatic
empty zone: 2.0.192.IN-ADDR.ARPA
Jan 11 08:45:56 ipa2.optimcloud.com named-pkcs11[2493]: automatic
empty zone: 100.51.198.IN-ADDR.ARPA
Jan 11 08:45:56 ipa2.optimcloud.com named-pkcs11[2493]: automatic
empty zone: 113.0.203.IN-ADDR.ARPA
Jan 11 08:45:56 ipa2.optimcloud.com named-pkcs11[2493]: automatic
empty zone: 255.255.255.255.IN-ADDR.ARPA
Jan 11 08:45:56 ipa2.optimcloud.com named-pkcs11[2493]: automatic
empty zone: 
0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA
Jan 11 08:45:56 ipa2.optimcloud.com named-pkcs11[2493]: automatic
empty zone: D.F.IP6.ARPA
Jan 11 08:45:56 ipa2.optimcloud.com named-pkcs11[2493]: automatic
empty zone: 8.E.F.IP6.ARPA
Jan 11 08:45:56 ipa2.optimcloud.com named-pkcs11[2493]: automatic
empty zone: 9.E.F.IP6.ARPA
Jan 11 08:45:56 ipa2.optimcloud.com named-pkcs11[2493]: automatic
empty zone: A.E.F.IP6.ARPA
Jan 11 08:45:56 ipa2.optimcloud.com named-pkcs11[2493]: automatic
empty zone: B.E.F.IP6.ARPA
Jan 11 08:45:56 ipa2.optimcloud.com named-pkcs11[2493]: automatic
empty zone: 8.B.D.0.1.0.0.2.IP6.ARPA
Jan 11 08:45:56 ipa2.optimcloud.com named-pkcs11[2493]:
/etc/named.conf:12: no forwarders seen; disabling forwarding
Jan 11 08:45:56 ipa2.optimcloud.com named-pkcs11[2493]: command
channel listening on 127.0.0.1#953
Jan 11 08:45:56 ipa2.optimcloud.com named-pkcs11[2493]: command
channel listening on ::1#953
Jan 11 08:45:56 ipa2.optimcloud.com named-pkcs11[2493]:
managed-keys-zone: journal file is out of date: removing journal file
Jan 11 08:45:56 ipa2.optimcloud.com named-pkcs11[2493]:
managed-keys-zone: loaded serial 45
Jan 11 08:45:56 ipa2.optimcloud.com named-pkcs11[2493]: shutting down
automatic empty zones to enable forwarding for domain '.'
Jan 11 08:45:56 ipa2.optimcloud.com named-pkcs11[2493]: zone
0.in-addr.arpa/IN: loaded serial 0
Jan 11 08:45:56 ipa2.optimcloud.com named-pkcs11[2493]: zone
1.0.0.127.in-addr.arpa/IN: loaded serial 0
Jan 11 08:45:56 ipa2.optimcloud.com named-pkcs11[2493]: zone
localhost.localdomain/IN: loaded serial 0
Jan 11 08:45:56 ipa2.optimcloud.com named-pkcs11[2493]: zone
localhost/IN: loaded serial 0
Jan 11 08:45:56 ipa2.optimcloud.com named-pkcs11[2493]: zone
1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa/IN:
loaded serial 0
Jan 11 08:45:56 ipa2.optimcloud.com named-pkcs11[2493]: all zones loaded
Jan 11 08:45:56 ipa2.optimcloud.com named-pkcs11[2493]: running
Jan 11 08:45:56 ipa2.optimcloud.com named-pkcs11[2493]: LDAP
configuration for instance 'ipa' synchronized
Jan 11 08:45:56 ipa2.optimcloud.com named-pkcs11[2493]: GSSAPI client step 1
Jan 11 08:45:56 ipa2.optimcloud.com named-pkcs11[2493]: GSSAPI client step 1
Jan 11 08:45:56 ipa2.optimcloud.com systemd[1]: Started Berkeley
Internet Name Domain (DNS) with native PKCS#11.
Jan 11 08:45:56 ipa2.optimcloud.com named-pkcs11[2493]: GSSAPI client step 1
Jan 11 08:45:56 ipa2.optimcloud.com named-pkcs11[2493]: GSSAPI client step 2
Jan 11 08:45:56 ipa2.optimcloud.com named-pkcs11[2493]: LDAP data for
instance 'ipa' are being synchronized, please ignore message 'all
zones loaded'
Jan 11 08:45:57 ipa2.optimcloud.com named-pkcs11[2493]: failed to
parse RR entry: resource record DN
'idnsname=_dmarc,idnsname=optimcloud.com.,cn=dns,dc=optimcloud,dc=com':
data '"v=DMARC1; p=reject; rua=mailto:postmas...@optimcloud.com;
ruf=mailto:ad...@optimcloud.com': unexpected end of input
Jan 11 08:45:57 ipa2.optimcloud.com named-pkcs11[2493]: update_record
(syncrepl) failed, resource record DN
'idnsname=_dmarc,idnsname=optimcloud.com.,cn=dns,dc=optimcloud,dc=com'
change type 0x1. Records can be outdated, run `rndc reload`:
unexpected end of input
Jan 11 08:45:57 ipa2.optimcloud.com named-pkcs11[2493]: zone
150.217.162.in-addr.arpa/IN: loaded serial 1484142357
Jan 11 08:45:57 ipa2.optimcloud.com named-pkcs11[2493]: zone
150.217.162.in-addr.arpa/IN: sending notifies (serial 1484142357)
Jan 11 08:45:57 ipa2.optimcloud.com named-pkcs11[2493]: zone
252.91.54.in-addr.arpa/IN: loaded serial 1484142357
Jan 11 08:45:57 ipa2.optimcloud.com named-pkcs11[2493]: error (network
unreachable) resolving 'ipa.optimcloud.com/A/IN':
2001:500:1::803f:235#53
Jan 11 08:45:57 ipa2.optimcloud.com named-pkcs11[2493]: error (network
unreachable) resolving

Re: [Freeipa-users] secondary out of sync on DNS again

2017-01-11 Thread Martin Basti


Please try to create a new test user if it is replicated to other replicas.


I see repl. conflicts please try to investigate them, it may cause a 
missing zone


https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html


could you check what do you have in journalctl -u named-pkcs11 on 
replica with missing entries?


Martin

On 11.01.2017 16:27, Outback Dingo wrote:

Not realliy, not like last time but
[root@ipa2 ~]# cd ipa_check_consistency/
[root@ipa2 ipa_check_consistency]# ./ipa_check_consistency -H
ipa2.optimcloud.com -d OPTIMCLOUD.COM
Directory Manager password:
FreeIPA servers:ipa2STATE
=
Active Users1   OK
Stage Users 0   OK
Preserved Users 0   OK
User Groups 4   OK
Hosts   8   OK
Host Groups 2   OK
HBAC Rules  1   OK
SUDO Rules  0   OK
DNS Zones   26  OK
LDAP Conflicts  YES FAIL
Ghost Replicas  NO  OK
Anonymous BIND  YES OK
Replication Status  ipa 0



[07/Jan/2017:23:59:33.034771024 -0500] slapd shutting down - signaling
operation threads - op stack size 1 max work q size 3 max work q stack
size 3
[07/Jan/2017:23:59:33.080148204 -0500] slapd shutting down - waiting
for 26 threads to terminate
[08/Jan/2017:00:01:43.342292791 -0500] SSL alert: Sending pin request
to SVRCore. You may need to run systemd-tty-ask-password-agent to
provide the password.
[08/Jan/2017:00:01:43.348739255 -0500] SSL alert: Security
Initialization: Enabling default cipher set.
[08/Jan/2017:00:01:43.349917267 -0500] SSL alert: Configured NSS Ciphers
[08/Jan/2017:00:01:43.350819261 -0500] SSL alert:
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384: enabled
[08/Jan/2017:00:01:43.352925341 -0500] SSL alert:
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA: enabled
[08/Jan/2017:00:01:43.354043098 -0500] SSL alert:
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256: enabled
[08/Jan/2017:00:01:43.354944795 -0500] SSL alert:
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA: enabled
[08/Jan/2017:00:01:43.355929413 -0500] SSL alert:
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384: enabled
[08/Jan/2017:00:01:43.356793063 -0500] SSL alert:
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA: enabled
[08/Jan/2017:00:01:43.357650823 -0500] SSL alert:
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256: enabled
[08/Jan/2017:00:01:43.358754848 -0500] SSL alert:
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA: enabled
[08/Jan/2017:00:01:43.359655681 -0500] SSL alert:
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384: enabled
[08/Jan/2017:00:01:43.360741758 -0500] SSL alert:
TLS_DHE_RSA_WITH_AES_256_CBC_SHA: enabled
[08/Jan/2017:00:01:43.361650705 -0500] SSL alert:
TLS_DHE_DSS_WITH_AES_256_CBC_SHA: enabled
[08/Jan/2017:00:01:43.362718051 -0500] SSL alert:
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256: enabled
[08/Jan/2017:00:01:43.363594439 -0500] SSL alert:
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256: enabled
[08/Jan/2017:00:01:43.365599343 -0500] SSL alert:
TLS_DHE_RSA_WITH_AES_128_CBC_SHA: enabled
[08/Jan/2017:00:01:43.366719360 -0500] SSL alert:
TLS_DHE_DSS_WITH_AES_128_CBC_SHA: enabled
[08/Jan/2017:00:01:43.368835924 -0500] SSL alert:
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256: enabled
[08/Jan/2017:00:01:43.370913228 -0500] SSL alert:
TLS_RSA_WITH_AES_256_GCM_SHA384: enabled
[08/Jan/2017:00:01:43.372972786 -0500] SSL alert:
TLS_RSA_WITH_AES_256_CBC_SHA: enabled
[08/Jan/2017:00:01:43.375008604 -0500] SSL alert:
TLS_RSA_WITH_AES_256_CBC_SHA256: enabled
[08/Jan/2017:00:01:43.377060277 -0500] SSL alert:
TLS_RSA_WITH_AES_128_GCM_SHA256: enabled
[08/Jan/2017:00:01:43.379147161 -0500] SSL alert:
TLS_RSA_WITH_AES_128_CBC_SHA: enabled
[08/Jan/2017:00:01:43.381215466 -0500] SSL alert:
TLS_RSA_WITH_AES_128_CBC_SHA256: enabled
[08/Jan/2017:00:01:43.410666701 -0500] SSL Initialization - Configured
SSL version range: min: TLS1.0, max: TLS1.2
[08/Jan/2017:00:01:43.412541954 -0500] 389-Directory/1.3.5.10
B2016.341. starting up
[08/Jan/2017:00:01:43.432516181 -0500] default_mr_indexer_create:
warning - plugin [caseIgnoreIA5Match] does not handle
caseExactIA5Match
[08/Jan/2017:00:01:43.455710217 -0500] WARNING: changelog: entry cache
size 2097152 B is less than db size 4096000 B; We recommend to
increase the entry cache size nsslapd-cachememsize.
[08/Jan/2017:00:01:43.461914913 -0500] Detected Disorderly Shutdown
last time Directory Server was running, recovering database.
[08/Jan/2017:00:01:43.832287548 -0500] schema-compat-plugin -
scheduled schema-compat-plugin tree scan in about 5 seconds after the
server startup!
[08/Jan/2017:00:01:43.857795379 -0500] NSACLPlugin - The ACL target
cn=groups,cn=compat,dc=optimcloud,dc=com does not exist
[08/Jan/2017:00:01:43.859681661 -0500] NSACLPlugin - The ACL target
cn=computers,cn=compat,dc=optimcloud,dc=com does not exist
[08/Jan/2017:00:01:43.861398809 -0500] NSACLPlugin - The ACL target
cn=ng,cn=compat,dc=optimcloud,dc=com does not exist

Re: [Freeipa-users] secondary out of sync on DNS again

2017-01-11 Thread Outback Dingo

Not realliy, not like last time but
[root@ipa2 ~]# cd ipa_check_consistency/
[root@ipa2 ipa_check_consistency]# ./ipa_check_consistency -H
ipa2.optimcloud.com -d OPTIMCLOUD.COM
Directory Manager password:
FreeIPA servers:ipa2STATE
=
Active Users1   OK
Stage Users 0   OK
Preserved Users 0   OK
User Groups 4   OK
Hosts   8   OK
Host Groups 2   OK
HBAC Rules  1   OK
SUDO Rules  0   OK
DNS Zones   26  OK
LDAP Conflicts  YES FAIL
Ghost Replicas  NO  OK
Anonymous BIND  YES OK
Replication Status  ipa 0



[07/Jan/2017:23:59:33.034771024 -0500] slapd shutting down - signaling
operation threads - op stack size 1 max work q size 3 max work q stack
size 3
[07/Jan/2017:23:59:33.080148204 -0500] slapd shutting down - waiting
for 26 threads to terminate
[08/Jan/2017:00:01:43.342292791 -0500] SSL alert: Sending pin request
to SVRCore. You may need to run systemd-tty-ask-password-agent to
provide the password.
[08/Jan/2017:00:01:43.348739255 -0500] SSL alert: Security
Initialization: Enabling default cipher set.
[08/Jan/2017:00:01:43.349917267 -0500] SSL alert: Configured NSS Ciphers
[08/Jan/2017:00:01:43.350819261 -0500] SSL alert:
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384: enabled
[08/Jan/2017:00:01:43.352925341 -0500] SSL alert:
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA: enabled
[08/Jan/2017:00:01:43.354043098 -0500] SSL alert:
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256: enabled
[08/Jan/2017:00:01:43.354944795 -0500] SSL alert:
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA: enabled
[08/Jan/2017:00:01:43.355929413 -0500] SSL alert:
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384: enabled
[08/Jan/2017:00:01:43.356793063 -0500] SSL alert:
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA: enabled
[08/Jan/2017:00:01:43.357650823 -0500] SSL alert:
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256: enabled
[08/Jan/2017:00:01:43.358754848 -0500] SSL alert:
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA: enabled
[08/Jan/2017:00:01:43.359655681 -0500] SSL alert:
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384: enabled
[08/Jan/2017:00:01:43.360741758 -0500] SSL alert:
TLS_DHE_RSA_WITH_AES_256_CBC_SHA: enabled
[08/Jan/2017:00:01:43.361650705 -0500] SSL alert:
TLS_DHE_DSS_WITH_AES_256_CBC_SHA: enabled
[08/Jan/2017:00:01:43.362718051 -0500] SSL alert:
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256: enabled
[08/Jan/2017:00:01:43.363594439 -0500] SSL alert:
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256: enabled
[08/Jan/2017:00:01:43.365599343 -0500] SSL alert:
TLS_DHE_RSA_WITH_AES_128_CBC_SHA: enabled
[08/Jan/2017:00:01:43.366719360 -0500] SSL alert:
TLS_DHE_DSS_WITH_AES_128_CBC_SHA: enabled
[08/Jan/2017:00:01:43.368835924 -0500] SSL alert:
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256: enabled
[08/Jan/2017:00:01:43.370913228 -0500] SSL alert:
TLS_RSA_WITH_AES_256_GCM_SHA384: enabled
[08/Jan/2017:00:01:43.372972786 -0500] SSL alert:
TLS_RSA_WITH_AES_256_CBC_SHA: enabled
[08/Jan/2017:00:01:43.375008604 -0500] SSL alert:
TLS_RSA_WITH_AES_256_CBC_SHA256: enabled
[08/Jan/2017:00:01:43.377060277 -0500] SSL alert:
TLS_RSA_WITH_AES_128_GCM_SHA256: enabled
[08/Jan/2017:00:01:43.379147161 -0500] SSL alert:
TLS_RSA_WITH_AES_128_CBC_SHA: enabled
[08/Jan/2017:00:01:43.381215466 -0500] SSL alert:
TLS_RSA_WITH_AES_128_CBC_SHA256: enabled
[08/Jan/2017:00:01:43.410666701 -0500] SSL Initialization - Configured
SSL version range: min: TLS1.0, max: TLS1.2
[08/Jan/2017:00:01:43.412541954 -0500] 389-Directory/1.3.5.10
B2016.341. starting up
[08/Jan/2017:00:01:43.432516181 -0500] default_mr_indexer_create:
warning - plugin [caseIgnoreIA5Match] does not handle
caseExactIA5Match
[08/Jan/2017:00:01:43.455710217 -0500] WARNING: changelog: entry cache
size 2097152 B is less than db size 4096000 B; We recommend to
increase the entry cache size nsslapd-cachememsize.
[08/Jan/2017:00:01:43.461914913 -0500] Detected Disorderly Shutdown
last time Directory Server was running, recovering database.
[08/Jan/2017:00:01:43.832287548 -0500] schema-compat-plugin -
scheduled schema-compat-plugin tree scan in about 5 seconds after the
server startup!
[08/Jan/2017:00:01:43.857795379 -0500] NSACLPlugin - The ACL target
cn=groups,cn=compat,dc=optimcloud,dc=com does not exist
[08/Jan/2017:00:01:43.859681661 -0500] NSACLPlugin - The ACL target
cn=computers,cn=compat,dc=optimcloud,dc=com does not exist
[08/Jan/2017:00:01:43.861398809 -0500] NSACLPlugin - The ACL target
cn=ng,cn=compat,dc=optimcloud,dc=com does not exist
[08/Jan/2017:00:01:43.862632485 -0500] NSACLPlugin - The ACL target
ou=sudoers,dc=optimcloud,dc=com does not exist
[08/Jan/2017:00:01:43.863764066 -0500] NSACLPlugin - The ACL target
cn=users,cn=compat,dc=optimcloud,dc=com does not exist
[08/Jan/2017:00:01:43.864911346 -0500] NSACLPlugin - The ACL target
cn=vaults,cn=kra,dc=optimcloud,dc=com does not exist
[08/Jan/2017:00:01:43.866162668 -0500] NSACLPlugin - The ACL target
cn=vaults,cn=kra,dc=optimcloud,dc=com does not exist

Re: [Freeipa-users] secondary out of sync on DNS again

2017-01-11 Thread Martin Basti




On 11.01.2017 15:32, Outback Dingo wrote:

not sure why, but the secondary freeipa server is out of sync by a
long shot now, missing dns domains and A records... tried
ipa-replica-manage force-sync --from ipa.optimcloud.com

doesnt seem to be working

HELP!



Do you see any errors in /var/log/dirsrv/slapd-*/errors on servers?

Martin

--
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] secondary out of sync on DNS again

2017-01-11 Thread Outback Dingo

not sure why, but the secondary freeipa server is out of sync by a
long shot now, missing dns domains and A records... tried
ipa-replica-manage force-sync --from ipa.optimcloud.com

doesnt seem to be working

HELP!

-- 
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] modify schema - add group email and display attribute

2017-01-11 Thread Petr Vobornik

On 01/11/2017 01:58 PM, Sandor Juhasz wrote:
> Ok,
> 
> OID - check
> ldapmodify - check
> python scripts - check
> These works on both ipa 3.x and ipa 4.x.
> So the basic functionality is there for the new object class.
> 
> js - i am stuck with, i have created the js files for the plugin, see below.
> 
> But i don't know how to generate the the index. Also i might be completely 
> wrong.
> 
> On ipa 3.x the js files are there, most probably the groups.js would exist as 
> i 
> expect it.
> But on the other hand on the ipa 4.x there is nothing but freeipa/core.js is 
> there.

You don't need to generate plugin index, it is generated automatically.

Just:
  mkdir /usr/share/ipa/ui/js/plugins/myplugin
  cp myplugin.js /usr/share/ipa/ui/js/plugins/myplugin

It should be automatically picked up by Web UI.

It will work only in RHEL 7/CentOS 7(FreeIPA 3.3+). Not RHEL 6(sort of
3.0/3.1/3.2)

On RHEL 6, there is /usr/share/ipa/ui/ext/extension.js which can contain
custom content to extend UI, but writing a plugin for it is much more
complicated so I'd rather avoid it.

> 
> Here is the plugin, i am trying to use:
> define([
>'freeipa/phases',
>'freeipa/group'],
>function(phases, group_mod) {
> // helper function
>  function get_item(array, attr, value) {
>for (var i=0,l=array.length; i  if (array[i][attr] === value) return array[i];
>}
>return null;
>  }
>  var groupmail_plugin = {};
> // adds 'mail' field into group details facet
>  groupmail_plugin.add_group_mail_pre_op = function() {
>var facet = get_item(group_mod.entity_spec.facets, '$type', 'details');
>var section = get_item(facet.sections, 'name', 'identity');
>section.fields.push({
>  name: 'mail',
>  label: 'Mail'
>});
>return true;
>  };
>  phases.on('customization', groupmail_plugin.add_group_mail_pre_op);
>  return groupmail_plugin;
> });
> 
> 
> *Sándor Juhász*
> System Administrator
> *ChemAxon**Ltd*.
> Building Hx, GraphiSoft Park, Záhony utca 7, Budapest, Hungary, H-1031
> Cell: +36704258964
> 
> 
> *From: *"Brian Candler" 
> *To: *"Sandor Juhasz" 
> *Cc: *freeipa-users@redhat.com
> *Sent: *Monday, January 2, 2017 6:41:02 PM
> *Subject: *Re: [Freeipa-users] modify schema - add group email and display 
> attribute
> 
> On 02/01/2017 11:53, Sandor Juhasz wrote:
>  > I would be really happy if anybody could assign an OID for the new
>  > objectcalss
> 
> You can get your own enterprise OID for free from here:
> 
> http://pen.iana.org/pen/PenApplication.page
> 
> Note that you only get one, so it's up to you to subdivide the space.
> For example: if you get 1.3.6.1.4.1.9, then you might decide to use:
> 
> 1.3.6.1.4.1.9.1 = LDAP object classes
> 
> 1.3.6.1.4.1.9.1.1 = myMailObjectClass
> 
> 1.3.6.1.4.1.9.1.2 = someOtherObjectClass
> 
> 1.3.6.1.4.1.9.2 = LDAP attributes
> 
> 1.3.6.1.4.1.9.2.1 = mySpecialAttribute
> 
> then later you can assign under 1.3.6.1.4.1.9.3 for something else
> that needs OIDs (e.g. SNMP MIBs) and so on.
> 
> 
> 


-- 
Petr Vobornik

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

Re: [Freeipa-users] pki-tomcat failure

2017-01-11 Thread Petr Vobornik

On 01/10/2017 09:31 PM, Bob Hinton wrote:
> Hi,
> 
> The pki-tomcatd services on our IPA servers seem to have stopped working.
> 
> This seems to be related to the expiry of several certificates -
> 
> [root@ipa001 ~]# getcert list | more
> Number of certificates and requests being tracked: 8.
> Request ID '20161230150048':
> status: MONITORING
> stuck: no
> key pair storage:
> type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='auditSigningCert
> cert-pki-ca',token='NSS Certificate DB',pin set
> certificate:
> type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='auditSigningCert
> cert-pki-ca',token='NSS Certificate DB'
> CA: dogtag-ipa-ca-renew-agent
> issuer: CN=Certificate Authority,O=LOCAL.COM
> subject: CN=CA Audit,O=LOCAL.COM
> expires: 2017-01-09 08:21:45 UTC
> key usage: digitalSignature,nonRepudiation
> pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad
> post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert
> "auditSigningCert cert-pki-ca"
> track: yes
> auto-renew: yes
> Request ID '20161230150049':
> status: MONITORING
> stuck: no
> key pair storage:
> type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='ocspSigningCert
> cert-pki-ca',token='NSS Certificate DB',pin set
> certificate:
> type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='ocspSigningCert
> cert-pki-ca',token='NSS Certificate DB'
> CA: dogtag-ipa-ca-renew-agent
> issuer: CN=Certificate Authority,O=LOCAL.COM
> subject: CN=OCSP Subsystem,O=LOCAL.COM
> expires: 2017-01-09 08:21:45 UTC
> key usage: digitalSignature,nonRepudiation,keyCertSign,cRLSign
> eku: id-kp-OCSPSigning
> pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad
> post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert
> "ocspSigningCert cert-pki-ca"
> track: yes
> auto-renew: yes
> 
> These were originally in CA_WORKING state, but I moved the clock back
> and restarted certmonger to try to renew them.


Certs above have:
   expires: 2017-01-09 08:21:45 UTC

But log has 10/Jan so the log is from the time when certs are expired.

Move time back when all certs reported by `getcert list` are valid.
Restart IPA. Resubmit all certs which are about to expire. Move time back.


> 
> 
> /var/log/pki/pki-tomcat/ca/debug contains
> 
> [10/Jan/2017:18:35:37][localhost-startStop-1]: makeConnection:
> errorIfDown true
> [10/Jan/2017:18:35:37][localhost-startStop-1]:
> SSLClientCertificateSelectionCB: Setting desired cert nickname to:
> subsystemCert cert-pki-ca
> [10/Jan/2017:18:35:37][localhost-startStop-1]: LdapJssSSLSocket: set
> client auth cert nickname subsystemCert cert-pki-ca
> [10/Jan/2017:18:35:37][localhost-startStop-1]:
> SSLClientCertificatSelectionCB: Entering!
> [10/Jan/2017:18:35:37][localhost-startStop-1]: Candidate cert:
> caSigningCert cert-pki-ca
> [10/Jan/2017:18:35:37][localhost-startStop-1]: Candidate cert:
> Server-Cert cert-pki-ca
> [10/Jan/2017:18:35:37][localhost-startStop-1]:
> SSLClientCertificateSelectionCB: returning: null
> [10/Jan/2017:18:35:37][localhost-startStop-1]: SSL handshake happened
> Could not connect to LDAP server host ipa001.mgmt.local.com port 636
> Error netscape.ldap.LDAPException: Authentication failed (48)
> at
> com.netscape.cmscore.ldapconn.LdapBoundConnFactory.makeConnection(LdapBoundConnFactory.java:205)
> at
> com.netscape.cmscore.ldapconn.LdapBoundConnFactory.init(LdapBoundConnFactory.java:166)
> at
> com.netscape.cmscore.ldapconn.LdapBoundConnFactory.init(LdapBoundConnFactory.java:130)
> at com.netscape.cmscore.dbs.DBSubsystem.init(DBSubsystem.java:654)
> at
> com.netscape.cmscore.apps.CMSEngine.initSubsystem(CMSEngine.java:1169)
> at
> com.netscape.cmscore.apps.CMSEngine.initSubsystems(CMSEngine.java:1075)
> at com.netscape.cmscore.apps.CMSEngine.init(CMSEngine.java:571)
> at com.netscape.certsrv.apps.CMS.init(CMS.java:187)
> at com.netscape.certsrv.apps.CMS.start(CMS.java:1616)
> at
> com.netscape.cms.servlet.base.CMSStartServlet.init(CMSStartServlet.java:114)
> at javax.servlet.GenericServlet.init(GenericServlet.java:158)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:288)
> at
> org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:285)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAsPrivileged(Subject.java:549)
> at
>

Re: [Freeipa-users] modify schema - add group email and display attribute

2017-01-11 Thread Sandor Juhasz

Ok, 

OID - check 
ldapmodify - check 
python scripts - check 
These works on both ipa 3.x and ipa 4.x. 
So the basic functionality is there for the new object class. 

js - i am stuck with, i have created the js files for the plugin, see below. 

But i don't know how to generate the the index. Also i might be completely 
wrong. 

On ipa 3.x the js files are there, most probably the groups.js would exist as i 
expect it. 
But on the other hand on the ipa 4.x there is nothing but freeipa/core.js is 
there. 

Here is the plugin, i am trying to use: 
define([ 
'freeipa/phases', 
'freeipa/group'], 
function(phases, group_mod) { 
// helper function 
function get_item(array, attr, value) { 
for (var i=0,l=array.length; i 
To: "Sandor Juhasz"  
Cc: freeipa-users@redhat.com 
Sent: Monday, January 2, 2017 6:41:02 PM 
Subject: Re: [Freeipa-users] modify schema - add group email and display 
attribute 

On 02/01/2017 11:53, Sandor Juhasz wrote: 
> I would be really happy if anybody could assign an OID for the new 
> objectcalss 

You can get your own enterprise OID for free from here: 

http://pen.iana.org/pen/PenApplication.page 

Note that you only get one, so it's up to you to subdivide the space. 
For example: if you get 1.3.6.1.4.1.9, then you might decide to use: 

1.3.6.1.4.1.9.1 = LDAP object classes 

1.3.6.1.4.1.9.1.1 = myMailObjectClass 

1.3.6.1.4.1.9.1.2 = someOtherObjectClass 

1.3.6.1.4.1.9.2 = LDAP attributes 

1.3.6.1.4.1.9.2.1 = mySpecialAttribute 

then later you can assign under 1.3.6.1.4.1.9.3 for something else 
that needs OIDs (e.g. SNMP MIBs) and so on. 
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] freeipa 4.4.0 and Ubuntu 14.04

2017-01-11 Thread Andy Brittingham

Thanks! I will take a look at that.

Andy

On 1/9/17 8:37 AM, Youenn PIOLET wrote:
> Hey there,
> 
> I got the same issue after upgrading my servers to 4.4.0
> The problem comes from duplicate entries in :
> cn=permissions,cn=pbac,dc=example,dc=com
> 
> I think FreeIPA upgrade fails to create ACL on pbac specific entries,
> resulting in a conflict entry creation.
> 
> The problem is that SSSD on Ubuntu 14.04 is crashing when reading pbac
> where cn contains symbol "+".
> You should check if you got these conflict entries in
> cn=permissions,cn=pbac,dc=example,dc=com and remove them. 
> 
> Ubuntu authentication was working for me directly after the suppression.
> 
> Regards,
> 
> --
> Youenn Piolet
> piole...@gmail.com 
> /
> /
> 
> 2017-01-09 8:56 GMT+01:00 Jakub Hrozek  >:
> 
> On Fri, Jan 06, 2017 at 11:48:07AM -0500, Andy Brittingham wrote:
> > Sorry for the delay, was doing some troubleshooting.
> >
> > Here is what I know now:
> >
> > The problem is on Ubuntu hosts using older sssd versions 1.11.8 (Ubuntu
> > 14.04).
> >
> > SSSD versions 1.13.4 (Ubuntu 16.04) and 1.13.3 (CentOS 6.8) both work.
> >
> > Users in the admin group can't log into these hosts.
> >
> > I created a newadmins group and assigned a new user to it. When I add 
> the
> > "User Administrator" role the new user can't log into the hosts with 
> older
> > sssd.
> >
> > As soon as I delete the "User Administrator" role, new user has access
> > again.
> 
> So is it a role membership or a group membership that makes the
> difference?
> 
> >
> > I've pasted the last bit of logs from a sssd_domain log below. I'd be 
> happy
> > to forward the entire log, or additional logs if they will be helpful.
> 
> The log only captures a user lookup, not a login, sorry..
> 
> (This might be expected if you log in e.g. with an SSH key, in which
> case journald should be the first thing to look at at least to poinpoint
> which piece denied access..)
> 
> --
> Manage your subscription for the Freeipa-users mailing list:
> https://www.redhat.com/mailman/listinfo/freeipa-users
> 
> Go to http://freeipa.org for more info on the project
> 
> 
> 
> 

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

Re: [Freeipa-users] Different cache on 2 IPA servers

2017-01-11 Thread Troels Hansen

Hi Sumit

- On Jan 11, 2017, at 12:51 PM, Sumit Bose sb...@redhat.com wrote:

> 
> I guess this is because the last update on one server was done with data
> from LDAP while the other used data from the Global Catalog. In general
> missing data in the GC should not remove the data read from LDAP, there
> is already https://fedorahosted.org/sssd/ticket/2474 to track this.

As always, looks spot on, and explains what we saw.


> 
> We plan to allow to configure sub-domains individually in one of the
> next releases, see https://fedorahosted.org/sssd/ticket/2599 .
> 
> In the meantime you might want to try id-overrides for users which have
> /bin/false set as shell in AD?
> 

Yes, it would be nice to have the ability to configure individual things on the 
AD domains.
For now, we'll implement ID override on users who we find to have this problem.

-- 
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] Different cache on 2 IPA servers

2017-01-11 Thread Sumit Bose

On Wed, Jan 11, 2017 at 11:01:22AM +0100, Troels Hansen wrote:
> Hi, we have just seen a weird issue, which I need some advice on. 
> 
> We have 2 IPA 4.4 servere in a AD trust and a number of Linux clients 
> connected. 
> 
> A little story of what we experienced. 
> We had a AD user which sometimes couldn't log in to a server, because his 
> shell was being set to /bin/false by SSSD. 
> 
> "sss_cache -E", deleting local cache in /var/lib/sssd/mc and db and 
> restarting SSSD sometimes led to the users having a correct shell set, but 
> still, after some hours most likely having his shell being set back to 
> /bin/false. 
> 
> We discovered that when the clients was connected to one IPA server the shell 
> was set to /bin/false and when connected to the other, the shell from SSSD, 
> default_shell was set. 
> 
> This led us to investigate the SSSD cache (in /var/lib/sssd/db/) on the IPA 
> serveres, and there we discovered that on one server a loginShell was set 
> whilst it wasn't on the other. 
> 
> ldapsearch the user on the AD servers had the loginShell: /bin/false 
> 
> However, one IPA server still had an idea that loginShell wasn't set. 
> 
> sss_cache -E on the IPA server correcthe the issue. 
> 
> This attribute have been on the user for ages, so do anyone have any idea of 
> how this can happen? 
> 
> sssd config and everything about the serveres are the same. Also, SSSD cache 
> config.ldb contained the same values on both servers. 
> 
> 
> Second question. The reason for the loginshell being set on some users is 
> that they used to be 
> Hi, we have just seen a weird issue, which I need some advice on. 
> 
> We have 2 IPA 4.4 servere in a AD trust and a number of Linux clients 
> connected. 
> 
> A little story of what we experienced. 
> We had a AD user which sometimes couldn't log in to a server, because his 
> shell was being set to /bin/false by SSSD. 
> 
> "sss_cache -E", deleting local cache in /var/lib/sssd/mc and db and 
> restarting SSSD sometimes led to the users having a correct shell set, but 
> still, after some hours most likely having his shell being set back to 
> /bin/false. 
> 
> We discovered that when the clients was connected to one IPA server the shell 
> was set to /bin/false and when connected to the other, the shell from SSSD, 
> default_shell was set. 
> 
> This led us to investigate the SSSD cache (in /var/lib/sssd/db/) on the IPA 
> serveres, and there we discovered that on one server a loginShell was set 
> whilst it wasn't on the other. 
> 
> ldapsearch the user on the AD servers had the loginShell: /bin/false 
> 
> However, one IPA server still had an idea that loginShell wasn't set. 
> 
> sss_cache -E on the IPA server correcthe the issue. 
> 
> This attribute have been on the user for ages, so do anyone have any idea of 
> how this can happen? 

I guess this is because the last update on one server was done with data
from LDAP while the other used data from the Global Catalog. In general
missing data in the GC should not remove the data read from LDAP, there
is already https://fedorahosted.org/sssd/ticket/2474 to track this.

> 
> So, the actual error was that the user was actually allowed to log in but as 
> we discovered the actual reason, the question is, why the cache isn't updated 
> and contains different content on the IPA servers. 
> 
> sssd config and everything about the serveres are the same. Also, SSSD cache 
> config.ldb contained the same values on both servers. 
> 
> 
> Second question. The reason for the loginshell being set on some users is 
> that they used to be QAU, which enabled the UNIX attributes on the user, and 
> disabling the user in QAS sets the shell to /bin/false. 
> So, what we would really like is to override if a user have a shell in AD, by 
> setting "ldap_user_shell = something-false" on the IPA servers, but this 
> isn't inherited to sub-domains? 
> 
> Can disabling shell's be accomplished somehow else? 

We plan to allow to configure sub-domains individually in one of the
next releases, see https://fedorahosted.org/sssd/ticket/2599 .

In the meantime you might want to try id-overrides for users which have
/bin/false set as shell in AD?

HTH

bye,
Sumit

> 
> 

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

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

[Freeipa-users] Different cache on 2 IPA servers

2017-01-11 Thread Troels Hansen

Hi, we have just seen a weird issue, which I need some advice on. 

We have 2 IPA 4.4 servere in a AD trust and a number of Linux clients 
connected. 

A little story of what we experienced. 
We had a AD user which sometimes couldn't log in to a server, because his shell 
was being set to /bin/false by SSSD. 

"sss_cache -E", deleting local cache in /var/lib/sssd/mc and db and restarting 
SSSD sometimes led to the users having a correct shell set, but still, after 
some hours most likely having his shell being set back to /bin/false. 

We discovered that when the clients was connected to one IPA server the shell 
was set to /bin/false and when connected to the other, the shell from SSSD, 
default_shell was set. 

This led us to investigate the SSSD cache (in /var/lib/sssd/db/) on the IPA 
serveres, and there we discovered that on one server a loginShell was set 
whilst it wasn't on the other. 

ldapsearch the user on the AD servers had the loginShell: /bin/false 

However, one IPA server still had an idea that loginShell wasn't set. 

sss_cache -E on the IPA server correcthe the issue. 

This attribute have been on the user for ages, so do anyone have any idea of 
how this can happen? 

sssd config and everything about the serveres are the same. Also, SSSD cache 
config.ldb contained the same values on both servers. 


Second question. The reason for the loginshell being set on some users is that 
they used to be 
Hi, we have just seen a weird issue, which I need some advice on. 

We have 2 IPA 4.4 servere in a AD trust and a number of Linux clients 
connected. 

A little story of what we experienced. 
We had a AD user which sometimes couldn't log in to a server, because his shell 
was being set to /bin/false by SSSD. 

"sss_cache -E", deleting local cache in /var/lib/sssd/mc and db and restarting 
SSSD sometimes led to the users having a correct shell set, but still, after 
some hours most likely having his shell being set back to /bin/false. 

We discovered that when the clients was connected to one IPA server the shell 
was set to /bin/false and when connected to the other, the shell from SSSD, 
default_shell was set. 

This led us to investigate the SSSD cache (in /var/lib/sssd/db/) on the IPA 
serveres, and there we discovered that on one server a loginShell was set 
whilst it wasn't on the other. 

ldapsearch the user on the AD servers had the loginShell: /bin/false 

However, one IPA server still had an idea that loginShell wasn't set. 

sss_cache -E on the IPA server correcthe the issue. 

This attribute have been on the user for ages, so do anyone have any idea of 
how this can happen? 

So, the actual error was that the user was actually allowed to log in but as we 
discovered the actual reason, the question is, why the cache isn't updated and 
contains different content on the IPA servers. 

sssd config and everything about the serveres are the same. Also, SSSD cache 
config.ldb contained the same values on both servers. 


Second question. The reason for the loginshell being set on some users is that 
they used to be QAU, which enabled the UNIX attributes on the user, and 
disabling the user in QAS sets the shell to /bin/false. 
So, what we would really like is to override if a user have a shell in AD, by 
setting "ldap_user_shell = something-false" on the IPA servers, but this isn't 
inherited to sub-domains? 

Can disabling shell's be accomplished somehow else? 


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

Re: [Freeipa-users] Asking for help with crashed freeIPA istance

Re: [Freeipa-users] pki-tomcat failure

Re: [Freeipa-users] CA crt renew -- encoding mismatch

Re: [Freeipa-users] secondary out of sync on DNS again [solved]

Re: [Freeipa-users] secondary out of sync on DNS again [solved]

Re: [Freeipa-users] secondary out of sync on DNS again [solved]

Re: [Freeipa-users] secondary out of sync on DNS again

Re: [Freeipa-users] secondary out of sync on DNS again

Re: [Freeipa-users] secondary out of sync on DNS again

Re: [Freeipa-users] secondary out of sync on DNS again

[Freeipa-users] secondary out of sync on DNS again

Re: [Freeipa-users] modify schema - add group email and display attribute

Re: [Freeipa-users] pki-tomcat failure

Re: [Freeipa-users] modify schema - add group email and display attribute

Re: [Freeipa-users] freeipa 4.4.0 and Ubuntu 14.04

Re: [Freeipa-users] Different cache on 2 IPA servers

Re: [Freeipa-users] Different cache on 2 IPA servers

[Freeipa-users] Different cache on 2 IPA servers

18 matches

Site Navigation

Mail list logo

Footer information