date:20160920

[Freeipa-users] Me Again

2016-09-20 Thread Ian Harding

I used to have a lot of replicas, but like a house of cards, it all came
crashing down.

I was down to two, that seemed to be replicating, but last few days I've
noticed that they haven't always been.

freeipa-sea.bpt.rocks is where we do all our admin.
seattlenfs.bpt.rocks is also up and running and can be used for
authentication.

When I noticed that logins were failing after password changes I did

ipa-replica-manage re-initialize --from=freeipa-sea.bpt.rocks

on seattlenfs.bpt.rocks and replication appeared to be working again.

Well it happened again, and this time I peeked at the dirsrv errors log
and saw some scary things having to do with the CA.

[19/Sep/2016:02:55:50 -0700] slapd_ldap_sasl_interactive_bind - Error:
could not perform interactive bind for id [] mech [GSSAPI]: LDAP error
-1 (Can't contact LDAP server) ((null)) errno 0 (Success)
[19/Sep/2016:02:55:50 -0700] slapi_ldap_bind - Error: could not perform
interactive bind for id [] authentication mechanism [GSSAPI]: error -1
(Can't contact LDAP server)
[19/Sep/2016:02:55:50 -0700] NSMMReplicationPlugin -
agmt="cn=meTofreeipa-sea.bpt.rocks" (freeipa-sea:389): Replication bind
with GSSAPI auth failed: LDAP error -1 (Can't contact LDAP server) ()
[19/Sep/2016:02:56:04 -0700] NSMMReplicationPlugin -
agmt="cn=meTofreeipa-sea.bpt.rocks" (freeipa-sea:389): Replication bind
with GSSAPI auth resumed
[20/Sep/2016:10:18:25 -0700] NSMMReplicationPlugin -
multimaster_be_state_change: replica dc=bpt,dc=rocks is going offline;
disabling replication
[20/Sep/2016:10:18:26 -0700] - WARNING: Import is running with
nsslapd-db-private-import-mem on; No other process is allowed to access
the database
[20/Sep/2016:10:18:29 -0700] - import userRoot: Workers finished;
cleaning up...
[20/Sep/2016:10:18:29 -0700] - import userRoot: Workers cleaned up.
[20/Sep/2016:10:18:29 -0700] - import userRoot: Indexing complete.
Post-processing...
[20/Sep/2016:10:18:29 -0700] - import userRoot: Generating
numsubordinates (this may take several minutes to complete)...
[20/Sep/2016:10:18:29 -0700] - import userRoot: Generating
numSubordinates complete.
[20/Sep/2016:10:18:29 -0700] - import userRoot: Gathering ancestorid
non-leaf IDs...
[20/Sep/2016:10:18:29 -0700] - import userRoot: Finished gathering
ancestorid non-leaf IDs.
[20/Sep/2016:10:18:29 -0700] - import userRoot: Creating ancestorid
index (new idl)...
[20/Sep/2016:10:18:29 -0700] - import userRoot: Created ancestorid index
(new idl).
[20/Sep/2016:10:18:29 -0700] - import userRoot: Flushing caches...
[20/Sep/2016:10:18:29 -0700] - import userRoot: Closing files...
[20/Sep/2016:10:18:29 -0700] - import userRoot: Import complete.
Processed 1324 entries in 3 seconds. (441.33 entries/sec)
[20/Sep/2016:10:18:29 -0700] NSMMReplicationPlugin -
multimaster_be_state_change: replica dc=bpt,dc=rocks is coming online;
enabling replication
[20/Sep/2016:10:18:29 -0700] NSMMReplicationPlugin - replica_reload_ruv:
Warning: new data for replica dc=bpt,dc=rocks does not match the data in
the changelog.
 Recreating the changelog file. This could affect replication with
replica's  consumers in which case the consumers should be reinitialized.
[20/Sep/2016:10:18:29 -0700] NSACLPlugin - The ACL target
cn=groups,cn=compat,dc=bpt,dc=rocks does not exist
[20/Sep/2016:10:18:29 -0700] NSACLPlugin - The ACL target
cn=computers,cn=compat,dc=bpt,dc=rocks does not exist
[20/Sep/2016:10:18:29 -0700] NSACLPlugin - The ACL target
cn=ng,cn=compat,dc=bpt,dc=rocks does not exist
[20/Sep/2016:10:18:29 -0700] NSACLPlugin - The ACL target
ou=sudoers,dc=bpt,dc=rocks does not exist
[20/Sep/2016:10:18:29 -0700] NSACLPlugin - The ACL target
cn=users,cn=compat,dc=bpt,dc=rocks does not exist
[20/Sep/2016:10:18:29 -0700] NSACLPlugin - The ACL target
cn=vaults,cn=kra,dc=bpt,dc=rocks does not exist
[20/Sep/2016:10:18:29 -0700] NSACLPlugin - The ACL target
cn=vaults,cn=kra,dc=bpt,dc=rocks does not exist
[20/Sep/2016:10:18:29 -0700] NSACLPlugin - The ACL target
cn=vaults,cn=kra,dc=bpt,dc=rocks does not exist
[20/Sep/2016:10:18:29 -0700] NSACLPlugin - The ACL target
cn=vaults,cn=kra,dc=bpt,dc=rocks does not exist
[20/Sep/2016:10:18:29 -0700] NSACLPlugin - The ACL target
cn=vaults,cn=kra,dc=bpt,dc=rocks does not exist
[20/Sep/2016:10:18:29 -0700] NSACLPlugin - The ACL target
cn=vaults,cn=kra,dc=bpt,dc=rocks does not exist
[20/Sep/2016:10:18:29 -0700] NSACLPlugin - The ACL target
cn=vaults,cn=kra,dc=bpt,dc=rocks does not exist
[20/Sep/2016:10:18:29 -0700] NSACLPlugin - The ACL target
cn=vaults,cn=kra,dc=bpt,dc=rocks does not exist
[20/Sep/2016:10:18:29 -0700] NSACLPlugin - The ACL target
cn=vaults,cn=kra,dc=bpt,dc=rocks does not exist
[20/Sep/2016:10:18:29 -0700] NSACLPlugin - The ACL target
cn=vaults,cn=kra,dc=bpt,dc=rocks does not exist
[20/Sep/2016:10:18:29 -0700] NSACLPlugin - The ACL target
cn=vaults,cn=kra,dc=bpt,dc=rocks does not exist
[20/Sep/2016:10:18:29 -0700] NSACLPlugin - The ACL target
cn=ad,cn=etc,dc=bpt,dc=rocks does not exist
[20/Sep/2016:10:18:29 -0700]

Re: [Freeipa-users] login auth fails then success

2016-09-20 Thread Jakub Hrozek

On Tue, Sep 20, 2016 at 02:03:38PM +, Larry Rosen wrote:
> Thanks, that explains a lot (I didn't catch the difference in auth services).
> Would this be mitigated by putting sss in front of files in nsswitch.conf)?
> 
> /etc/nsswitchconf:
> passwd: files sss
> shadow: files sss
> group:  files sss

No, NSS is a separate interface. You can experiment with adding
pam_localuser.so before pam_unix, though.

btw this is how recent Fedora releases configure their PAM stack:
authrequired  pam_env.so
authsufficientpam_fprintd.so
auth[default=1 success=ok] pam_localuser.so
auth[success=done ignore=ignore default=die] pam_unix.so nullok 
try_first_pass
authrequisite pam_succeed_if.so uid >= 1000 quiet_success
authsufficientpam_sss.so forward_pass
authrequired  pam_deny.so

But watch out, PAM stacks are inherently distro-specific and I don't
remember what exactly you're running.

-- 
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] login auth fails then success

2016-09-20 Thread Larry Rosen

Thanks, that explains a lot (I didn't catch the difference in auth services).
Would this be mitigated by putting sss in front of files in nsswitch.conf)?

/etc/nsswitchconf:
passwd: files sss
shadow: files sss
group:  files sss

Date: Sun, 18 Sep 2016 22:14:59 +0200
From: Jakub Hrozek 
To: freeipa-users@redhat.com
Subject: Re: [Freeipa-users] login auth fails then success
Message-ID: <20160918201459.uhijnc4gyfykgzic@hendrix>
Content-Type: text/plain; charset=us-ascii

On Fri, Sep 16, 2016 at 06:23:03PM +, Larry Rosen wrote:
> Sorry I thought I had pasted these previously:
> 
> What other logs do I need to add (maybe from the IPA server)?
> 
> Client system's /var/log/secure:
> 
> Sep 13 19:12:33 il10-app-xfs udcs: pam_unix(login:auth): 
> authentication failure; logname= uid=0 euid=0 tty= ruser= rhost=  
> user=il10web Sep 13 19:12:33 il10-app-xfs udcs: pam_sss(login:auth): 
> authentication success; logname= uid=0 euid=0 tty= ruser= rhost= 
> user=il10web Sep 13 19:18:11 il10-app-xfs udcs: pam_unix(login:auth): 
> authentication failure; logname= uid=0 euid=0 tty= ruser= rhost=  
> user=il10web Sep 13 19:18:11 il10-app-xfs udcs: pam_sss(login:auth): 
> authentication success; logname= uid=0 euid=0 tty= ruser= rhost= 
> user=il10web Sep 13 19:22:52 il10-app-xfs udcs: pam_unix(login:auth): 
> authentication failure; logname= uid=0 euid=0 tty= ruser= rhost=  
> user=il10web Sep 13 19:22:53 il10-app-xfs udcs: pam_sss(login:auth): 
> authentication success; logname= uid=0 euid=0 tty= ruser= rhost= 
> user=il10web Sep 13 19:23:49 il10-app-xfs udcs: pam_unix(login:auth): 
> authentication failure; logname= uid=0 euid=0 tty= ruser= rhost=  
> user=il10web Sep 13 19:23:49 il10-app-xfs udcs: pam_sss(login:auth): 
> authentication success; logname= uid=0 euid=0 tty= ruser= rhost= 
> user=il10web Sep 13 19:28:24 il10-app-xfs udcs: pam_unix(login:auth): 
> authentication failure; logname= uid=0 euid=0 tty= ruser= rhost=  
> user=il10web Sep 13 19:28:24 il10-app-xfs udcs: pam_sss(login:auth): 
> authentication success; logname= uid=0 euid=0 tty= ruser= rhost= 
> user=il10web Sep 13 19:29:27 il10-app-xfs udcs: pam_unix(login:auth): 
> authentication failure; logname= uid=0 euid=0 tty= ruser= rhost=  
> user=il10web Sep 13 19:29:27 il10-app-xfs udcs: pam_sss(login:auth): 
> authentication success; logname= uid=0 euid=0 tty= ruser= rhost= 
> user=il10web

I think these are expected. Authentication using pam_unix fails because 
pam_unix doesn't know this particular users and then pam_sss succeeds. I wonder 
if the best way to deal with the log messages is just to configure logrotate a 
bit more aggressively?

> 
> -Original Message-
> From: Rob Crittenden [mailto:rcrit...@redhat.com]
> Sent: Friday, September 16, 2016 1:39 PM
> To: Larry Rosen ; 
> freeipa-users@redhat.com
> Subject: Re: [Freeipa-users] login auth fails then success
> 
> Larry Rosen wrote:
> > We have a web app that logs in using a service (automated login 
> > user, non-expiring, non-failure count) account that leaves these log 
> > entries all day long.  This does not appear to cause any problems, 
> > it just make my logs grow unnecessarily and creates a lot of "noise" in the 
> > log.
> >
> > Any ideas why it initially fails and then works?**
> 
> Logs where? Can we see them?
> 
> rob
> 
> 
> --
> Manage your subscription for the Freeipa-users mailing list:
> https://www.redhat.com/mailman/listinfo/freeipa-users
> Go to http://freeipa.org for more info on the project

-- 
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] certificates not renewing CA_UNREACHEABLE

2016-09-20 Thread Natxo Asenjo

ok, so all certs are renewed (dogldap and http).

On Tue, Sep 20, 2016 at 11:49 AM, Natxo Asenjo 
wrote:

>
>
> On Mon, Sep 19, 2016 at 5:27 PM, Rob Crittenden 
> wrote:
>
>> Natxo Asenjo wrote:
>>
>>> hi,
>>>
>>>
>>> On Fri, Sep 16, 2016 at 4:22 PM, Rob Crittenden >>
>> Ok, how about we work around the problem.
>>
>
> Gladly ;-)
>
>
>> Since it is failing on the revocation what you might try is removing the
>> userCertificate value from the ldap/kdc01.unix.iriszorg.nl service entry.
>>
>> I think this will work:
>>
>> $ ipa service-show ldap/kdc01.unix.iriszorg.nl |grep Serial
>> 
>>
>> $ ipa service-mod --certificate= ldap/kdc01.unix.iriszorg.nl
>>
>> If this doesn't work you can use ldapmodify to delete the usercertificate
>> value.
>>
>> This will remove the certificate value so there is nothing to revoke and
>> a new cert will be saved (hopefully).
>>
>> Now try to resubmit the request via certmonger.
>>
>> It if works then you can run ipa cert-revooke 
>>
>> It isn't a great answer long-term because it is really just working
>> around the problem but it should get the certs renewed.
>>
>>
> ok, so I restarted the httpd service then I could use ipa service-show:
>
> $ ipa service-show ldap/kdc01.unix.iriszorg.nl |grep Serial
>   Serial Number: 175
>   Serial Number (hex): 0xAF
> bash-4.1$ ipa service-mod --certificate= ldap/kdc01.unix.iriszorg.nl
> ---
> Modified service "ldap/kdc01.unix.iriszorg...@unix.iriszorg.nl"
> ---
>   Principal: ldap/kdc01.unix.iriszorg...@unix.iriszorg.nl
>   Managed by: kdc01.unix.iriszorg.nl
>
>
> bash-4.1$ sudo ipa-getcert resubmit -i 20121107212513
> Resubmitting "20121107212513" to "IPA".
> bash-4.1$ sudo getcert list
> Number of certificates and requests being tracked: 8.
> Request ID '20121107212513':
> status: CA_UNREACHABLE
> ca-error: Server failed request, will retry: 4301 (RPC failed at
> server.  Certificate operation cannot be completed: Failure decoding
> Certificate Signing Request).
> stuck: yes
> key pair storage: type=NSSDB,location='/etc/
> dirsrv/slapd-UNIX-IRISZORG-NL',nickname='Server-Cert',token='NSS
> Certificate DB',pinfile='/etc/dirsrv/slapd-UNIX-IRISZORG-NL/pwdfile.txt'
> certificate: type=NSSDB,location='/etc/
> dirsrv/slapd-UNIX-IRISZORG-NL',nickname='Server-Cert',token='NSS
> Certificate DB'
> CA: IPA
> issuer: CN=Certificate Authority,O=UNIX.IRISZORG.NL
> subject: CN=kdc01.unix.iriszorg.nl,O=UNIX.IRISZORG.NL
> expires: 2016-10-12 10:49:24 UTC
> eku: id-kp-serverAuth,id-kp-clientAuth
> pre-save command:
> post-save command: /usr/lib/ipa/certmonger/restart_dirsrv
> UNIX-IRISZORG-NL
> track: yes
> auto-renew: yes
>
>
>
> the certificate is gone:
> $ ipa service-show ldap/kdc01.unix.iriszorg.nl
> ipa: ERROR: Could not create log_dir u'/home/jose.admin/.ipa/log'
>   Principal: ldap/kdc01.unix.iriszorg...@unix.iriszorg.nl
>   Keytab: True
>   Managed by: kdc01.unix.iriszorg.nl
>
>
> But then I thought, what the hell, let's try again, restarted httpd,
> resubmitted it, and now it did work ;-)
>
> $ ipa service-show ldap/kdc01.unix.iriszorg.nl
>   Principal: ldap/kdc01.unix.iriszorg...@unix.iriszorg.nl
>   Certificate: MIIDrDCCApSgAwIBAgICAPUwDQYJKo
> ZIhvcNAQELBQAwOzEZMBcGA1UEChMQVU5JWC5JUklTWk9SRy5OTDEeMBwGA1
> UEAxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTE2MDkyMDA4MDY1OFoXDT
> E4MDkyMTA4MDY1OFowPDEZMBcGA1UEChMQVU5JWC5JUklTWk9SRy5OTDEfMB
> 0GA1UEAxMWa2RjMDEudW5peC5pcmlzem9yZy5ubDCCASIwDQYJKoZIhvcNAQ
> EBBQADggEPADCCAQoCggEBAO2QVqrFRb/Q5dhkAi7BK29BJhqTvbaH3bNDLvhe1
> snyChdlr/AIwrJj/53Ti2eJ7u1BtV7u3gSwQ3/xJ0HwUZmOEQHCNDrjcGy+
> iw7lqkC5NaZ8AGt8bSTGWwnJvEGWrb3uEJzVZf+xB5eZa8vFXr+
> Jlcfoq8DbVZhX274pmpVfQOnRckD+AmncuEItHpcJCCHneF0QzA5DQqlTPUFerFm3F/iI/
> k6g9XbHQaNejcUYdhXpy9q0mEuBIIsEzTeNWTTEsUYX5TPVEsN3x2feA0icx
> R6bUTeg2BqSu7ZOuM55iBp3l0d9UAQ7W7yh76FI/Bqz8vIMdS6VsurPS4asLa8CAwEAAaO
> BuDCBtTAfBgNVHSMEGDAWgBSjl+SKLrjPPuoz8ryT1iPeqYQ2aDBEBggr
> BgEFBQcBAQQ4MDYwNAYIKwYBBQUHMAGGKGh0dHA6Ly9rZGMwMS51bml4Lmly
> aXN6b3JnLm5sOjgwL2NhL29jc3AwDgYDVR0PAQH/BAQDAgTwMB0GA1UdJQQWMBQGCCsGAQ
> UFBwMBBggrBgEFBQcDAjAdBgNVHQ4EFgQUBIRsG98GBkIyB/
> BgQKloUlLEJeEwDQYJKoZIhvcNAQELBQADggEBAHN+ggklVf2uzaePwEI9rMObe0WZeOyCLZ
> xEtigDaJIHkq3GzkugxcG8ivD/LnuF0D8m07npfpIMC3QRUJQjFjz6E3rKtqau0QY0BO+
> Dwg1TzItQqXxgHtCqcQ7bmahj2AMPRNUXeZck0p/eueG4wj2kbLwTLU6cOfwnT4IOfszAS
> 9GCql6oQIXlOfG6i6DAodBpgWziDfIrRJsJi4ZE+FvJL/ImJDdW+
> En50UyGp0n31oMSDIxWf1bdWUctSEYhcy9JftzkitNm1FD+a1HzeYyuHthzlHHcSIXN/
> kXRSGktpe8VHE5XLtKnH92vmkMnyxZvE///2+ExHXIAOkwq3ck=
>   Keytab: True
>   Managed by: kdc01.unix.iriszorg.nl
>   Subject: CN=kdc01.unix.iriszorg.nl,O=UNIX.IRISZORG.NL
>   Serial Number: 245
>   Serial Number (hex): 0xF5
>   Issuer: CN=Certificate Authority,O=UNIX.IRISZORG.NL
>   Not Before: Tue Sep

Re: [Freeipa-users] 3rd party Cert install now IPA total broken

2016-09-20 Thread Günther J . Niederwimmer

Hello.

Thanks for the first help,

Am Montag, 19. September 2016, 12:02:19 schrieb Florence Blanc-Renaud:
> On 09/16/2016 03:06 PM, Günther J. Niederwimmer wrote:
> > Hello,
> > Freeipa 4.3.1
> > 
> > I have now install a 3rd Party Certificat from Startcom now my IPA is
> > total
> > broken?

> > ipa-cacert-manage -p '' -n STARTCOM-ROOT -t C,, install
> > root.crt

I mean this is the wrong cert I installed :-(.

Is it possible to overwrite or delete and make it new. this file is the ROOT-CA 
from STARTCOM ("30 Years") 
 
> > ipa-certupdate
> > 
> > ipa-server-certinstall -w -d ipa_3rd_ca.p12

This was wrong, I delete all this installed certs with
Certutil -d . -D -n xxx
 
> > I create this p12 with key.pem, cert.pem root.crt

now i create a new p12 with I hope the correct certs

I become from Startcom a httpd zip file with 1_root_bundle.crt ("15 Years")and  
my wild-card Certificate this I included in my new created p12 with my key.pem.

This p12 I Installed on the first master with

pk12util -v -i ipa_4gjn_ca.p12 -d /etc/httpd/alias -k 
/etc/httpd/alias/pwdfile.txt -W 

pk12util -v -i ipa_4gjn_ca.p12 -d /etc/dirsrv/slapd-4GJN-COM -k 
/etc/dirsrv/slapd-4GJN-COM/pwdfile.txt -W xxx
and
pk12util -v -i ipa_4gjn_ca.p12 -d /var/lib/pki/pki-tomcat/alias -k 
/etc/pki/pki-tomcat/pwdfile.txt -W x

I change the nss.conf and I hope the correct file in /etc/dirsrv/slapd-
/dsl.ldif

Then I change in all NSS DB the StartCOM Cert (1_root_bundle.crt) with name 
STARTCOM-ROOT to
certutil -d . -M -t C,, -n STARCOM-ROOT


afterward I make a reboot and a test
ipactl status
Directory Service: RUNNING
krb5kdc Service: RUNNING
kadmin Service: RUNNING
named Service: RUNNING
ipa_memcached Service: RUNNING
httpd Service: RUNNING
ipa-custodia Service: RUNNING
pki-tomcatd Service: RUNNING
ipa-otpd Service: RUNNING
ipa-ods-exporter Service: STOPPED
ods-enforcerd Service: RUNNING
ipa-dnskeysyncd Service: RUNNING
ipa: INFO: The ipactl command was successful

Why is ipa-ods-exporter Service always STOPPED ??

The next I Test a login on the Web UI from IPA, this is now also working ;-)


the QUESTION is now what is with the second master and the IPA- clients
Now (?) I have also found the ipa-backup ;-) OK, for the next Problem now I 
know it :-). 

Have I to repeat this all on the second Master ?

and what is the correct way to inform the clients ?

Thanks again for a answer,
 
> Hi,
> 
> there were some issues with ipa-server-certinstall (see tickets #4785,
> #4786 and #6263).
> In order to check your configuration, you must make sure that the NSS
> DBs for Apache and the LDAP server (/etc/httpd/alias,
> /var/lib/pki/pki-tomcat/alias, /etc/dirsrv/slapd-DOMxx) contain:
> - the server certificate with flags u,u,u (= the one contained in
> ipa_3rd_ca.p12)
> - the certificate of the CA which signed the server certificate, with
> flags C,, (= the one contained in root.rt)
> 
> Then you can also check if the nickname for the server cert is properly
> set in /etc/httpd/conf.d/nss.conf (in the directive NSSNickname), and in
> the LDAP entry cn=RSA,cn=encryption,cn=config (in the attribute
> nsSSLPersonalitySSL).
> 
> If this doesn't fix the issue, the logs of pki-tomcat/ca/debug may
> provide more information.
> 
> Also note that it is important to run ipa-certupdate on all the clients
> and replicas in order to install the new certificates in the NSS DBs
> *before* you run ipa-server-certinstall.
> 
> Hope this helps,
> Flo.
> 
> > the kerberos don't start anymore ?
> > The Error Is
> > 
> >  Unspecified GSS failure.Minor (2529639068): Cannot contact any KDC for
> >  realm> 
> > '4GJN.COM'
> > 
> > after insert in nss.conf
> > "NSSEnforceValidCerts off"
> > 
> > ipactl restart  is starting (?) but
> > 
> > ipactl status tell me
> > Directory Service: RUNNING
> > krb5kdc Service: RUNNING
> > kadmin Service: RUNNING
> > named Service: RUNNING
> > ipa_memcached Service: RUNNING
> > httpd Service: RUNNING
> > ipa-custodia Service: RUNNING
> > pki-tomcatd Service: RUNNING
> > ipa-otpd Service: RUNNING
> > ipa-ods-exporter Service: STOPPED
> > ods-enforcerd Service: RUNNING
> > ipa-dnskeysyncd Service: RUNNING
> > ipa: INFO: The ipactl command was successful
> > 
> > with certutil -d /etc/httpd/alias -L I have now this
> > Certificate Nickname Trust
> > Attributes> 
> >  SSL,S/MIME,JA
> >  R/XPI
> > 
> > Signing-Cert u,u,u
> > 4GJN_CA_FILE u,u,u
> > ipaCert  u,u,u
> > 4GJN.COM IPA CA  CT,C,C
> > STARTCOM-ROOTC,,
> > 
> > I can  Insert in nss.conf by the
> > #NSSNickname "Signing-Cert" original
> > or
> >

[Freeipa-users] IPA Server is not coming backup

2016-09-20 Thread Deepak Dimri

Hi All,
My IPA Server was working all fine until i tried restarting it using "ipactl 
restart"  and now i am ended with these errors :( 








[root@ip-172-31-25-165 plugins]# ipactl restartStarting Directory 
ServiceRestarting krb5kdc ServiceRestarting kadmin ServiceStarting named 
ServiceJob for named-pkcs11.service failed because the control process exited 
with error code. See "systemctl status named-pkcs11.service" and "journalctl 
-xe" for details.Failed to start named ServiceShutting down















Aborting ipactl
This is what i get with  "systemctl status named-pkcs11.service"
[root@ip-172-31-25-165 plugins]# systemctl status named-pkcs11.service● 
named-pkcs11.service - Berkeley Internet Name Domain (DNS) with native PKCS#11  
 Loaded: loaded (/usr/lib/systemd/system/named-pkcs11.service; disabled; vendor 
preset: disabled)   Active: failed (Result: exit-code) since Tue 2016-09-20 
06:28:03 EDT; 1min 2s ago  Process: 3281 ExecStart=/usr/sbin/named-pkcs11 -u 
named $OPTIONS (code=exited, status=1/FAILURE)  Process: 3278 
ExecStartPre=/bin/bash -c if [ ! "$DISABLE_ZONE_CHECKING" == "yes" ]; then 
/usr/sbin/named-checkconf -z /etc/named.conf; else echo "Checking of zone files 
is disabled"; fi (code=exited, status=0/SUCCESS)
Sep 20 06:28:03 ip-172-31-25-165.us-west-2.compute.internal named-pkcs11[3284]: 
GSSAPI Error: Unspecified GSS failure.  Minor code may provide more information 
(Server krbtgt/US-WEST-2.C...database)Sep 20 06:28:03 
ip-172-31-25-165.us-west-2.compute.internal named-pkcs11[3284]: LDAP error: 
Local error: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure.  
Minor code may...er failedSep 20 06:28:03 
ip-172-31-25-165.us-west-2.compute.internal named-pkcs11[3284]: couldn't 
establish connection in LDAP connection pool: failureSep 20 06:28:03 
ip-172-31-25-165.us-west-2.compute.internal named-pkcs11[3284]: dynamic 
database 'ipa' configuration failed: failureSep 20 06:28:03 
ip-172-31-25-165.us-west-2.compute.internal named-pkcs11[3284]: loading 
configuration: failureSep 20 06:28:03 
ip-172-31-25-165.us-west-2.compute.internal named-pkcs11[3284]: exiting (due to 
fatal error)Sep 20 06:28:03 ip-172-31-25-165.us-west-2.compute.internal 
systemd[1]: named-pkcs11.service: control process exited, code=exited 
status=1Sep 20 06:28:03 ip-172-31-25-165.us-west-2.compute.internal systemd[1]: 
Failed to start Berkeley Internet Name Domain (DNS) with native PKCS#11.Sep 20 
06:28:03 ip-172-31-25-165.us-west-2.compute.internal systemd[1]: Unit 
named-pkcs11.service entered failed state.Sep 20 06:28:03 
ip-172-31-25-165.us-west-2.compute.internal systemd[1]: named-pkcs11.service 
failed.
























Hint: Some lines were ellipsized, use -l to show in full.
output from "journalctl -xe" is as below:
[root@ip-172-31-25-165 ec2-user]# journalctl -xeSep 20 06:37:00 
ip-172-31-25-165.us-west-2.compute.internal named-pkcs11[3511]: option 
'serial_autoincrement' is not supported, ignoringSep 20 06:37:00 
ip-172-31-25-165.us-west-2.compute.internal named-pkcs11[3511]: GSSAPI client 
step 1Sep 20 06:37:00 ip-172-31-25-165.us-west-2.compute.internal 
named-pkcs11[3511]: GSSAPI client step 1Sep 20 06:37:00 
ip-172-31-25-165.us-west-2.compute.internal named-pkcs11[3511]: GSSAPI Error: 
Unspecified GSS failure.  Minor code may provide more information Sep 20 
06:37:00 ip-172-31-25-165.us-west-2.compute.internal named-pkcs11[3511]: LDAP 
error: Local error: SASL(-1): generic failure: GSSAPI Error: Unspecified GSSep 
20 06:37:00 ip-172-31-25-165.us-west-2.compute.internal named-pkcs11[3511]: 
couldn't establish connection in LDAP connection pool: failureSep 20 06:37:00 
ip-172-31-25-165.us-west-2.compute.internal named-pkcs11[3511]: dynamic 
database 'ipa' configuration failed: failureSep 20 06:37:00 
ip-172-31-25-165.us-west-2.compute.internal named-pkcs11[3511]: loading 
configuration: failureSep 20 06:37:00 
ip-172-31-25-165.us-west-2.compute.internal named-pkcs11[3511]: exiting (due to 
fatal error)Sep 20 06:37:00 ip-172-31-25-165.us-west-2.compute.internal 
systemd[1]: named-pkcs11.service: control process exited, code=exited 
status=1Sep 20 06:37:00 ip-172-31-25-165.us-west-2.compute.internal systemd[1]: 
Failed to start Berkeley Internet Name Domain (DNS) with native PKCS#11.-- 
Subject: Unit named-pkcs11.service has failed-- Defined-By: systemd-- Support: 
http://lists.freedesktop.org/mailman/listinfo/systemd-devel-- -- Unit 
named-pkcs11.service has failed.-- -- The result is failed.Sep 20 06:37:00 
ip-172-31-25-165.us-west-2.compute.internal systemd[1]: Unit 
named-pkcs11.service entered failed state.Sep 20 06:37:00 
ip-172-31-25-165.us-west-2.compute.internal systemd[1]: named-pkcs11.service 
failed.Sep 20 06:37:00 ip-172-31-25-165.us-west-2.compute.internal 
polkitd[529]: Unregistered Authentication Agent for unix-process:3498:364279453 
(system bus name :1.Sep 20 06:37:00 ip-172-31-25-165.us-west-2.compute.internal 
polkitd[529]: Registered Authentication Agent

Re: [Freeipa-users] IPA Server is not coming backup

2016-09-20 Thread Petr Spacek

Hi,

The important line is around

> named-pkcs11[3511]: GSSAPI Error: Unspecified GSS failure.  Minor code may
provide more information

Unfortunately the log is truncated so it does not show the actual error.

Please see
https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/NamedCannotStart

I hope it helps.
Petr^2 Spacek

On 20.9.2016 12:45, Deepak Dimri wrote:
> Hi All,
> My IPA Server was working all fine until i tried restarting it using "ipactl 
> restart"  and now i am ended with these errors :( 
> 
> 
> 
> 
> 
> 
> 
> 
> [root@ip-172-31-25-165 plugins]# ipactl restartStarting Directory 
> ServiceRestarting krb5kdc ServiceRestarting kadmin ServiceStarting named 
> ServiceJob for named-pkcs11.service failed because the control process exited 
> with error code. See "systemctl status named-pkcs11.service" and "journalctl 
> -xe" for details.Failed to start named ServiceShutting down
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Aborting ipactl
> This is what i get with  "systemctl status named-pkcs11.service"
> [root@ip-172-31-25-165 plugins]# systemctl status named-pkcs11.service● 
> named-pkcs11.service - Berkeley Internet Name Domain (DNS) with native 
> PKCS#11   Loaded: loaded (/usr/lib/systemd/system/named-pkcs11.service; 
> disabled; vendor preset: disabled)   Active: failed (Result: exit-code) since 
> Tue 2016-09-20 06:28:03 EDT; 1min 2s ago  Process: 3281 
> ExecStart=/usr/sbin/named-pkcs11 -u named $OPTIONS (code=exited, 
> status=1/FAILURE)  Process: 3278 ExecStartPre=/bin/bash -c if [ ! 
> "$DISABLE_ZONE_CHECKING" == "yes" ]; then /usr/sbin/named-checkconf -z 
> /etc/named.conf; else echo "Checking of zone files is disabled"; fi 
> (code=exited, status=0/SUCCESS)
> Sep 20 06:28:03 ip-172-31-25-165.us-west-2.compute.internal 
> named-pkcs11[3284]: GSSAPI Error: Unspecified GSS failure.  Minor code may 
> provide more information (Server krbtgt/US-WEST-2.C...database)Sep 20 
> 06:28:03 ip-172-31-25-165.us-west-2.compute.internal named-pkcs11[3284]: LDAP 
> error: Local error: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS 
> failure.  Minor code may...er failedSep 20 06:28:03 
> ip-172-31-25-165.us-west-2.compute.internal named-pkcs11[3284]: couldn't 
> establish connection in LDAP connection pool: failureSep 20 06:28:03 
> ip-172-31-25-165.us-west-2.compute.internal named-pkcs11[3284]: dynamic 
> database 'ipa' configuration failed: failureSep 20 06:28:03 
> ip-172-31-25-165.us-west-2.compute.internal named-pkcs11[3284]: loading 
> configuration: failureSep 20 06:28:03 
> ip-172-31-25-165.us-west-2.compute.internal named-pkcs11[3284]: exiting (due 
> to fatal error)Sep 20 06:28:03 ip-172-31-25-165.us-west-2.compute.internal 
> systemd[1]: named-pkcs11.service: control process exited, code=exited 
> status=1Sep 20 06:28:03 ip-172-31-25-165.us-west-2.compute.internal 
> systemd[1]: Failed to start Berkeley Internet Name Domain (DNS) with native 
> PKCS#11.Sep 20 06:28:03 ip-172-31-25-165.us-west-2.compute.internal 
> systemd[1]: Unit named-pkcs11.service entered failed state.Sep 20 06:28:03 
> ip-172-31-25-165.us-west-2.compute.internal systemd[1]: named-pkcs11.service 
> failed.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Hint: Some lines were ellipsized, use -l to show in full.
> output from "journalctl -xe" is as below:
> [root@ip-172-31-25-165 ec2-user]# journalctl -xeSep 20 06:37:00 
> ip-172-31-25-165.us-west-2.compute.internal named-pkcs11[3511]: option 
> 'serial_autoincrement' is not supported, ignoringSep 20 06:37:00 
> ip-172-31-25-165.us-west-2.compute.internal named-pkcs11[3511]: GSSAPI client 
> step 1Sep 20 06:37:00 ip-172-31-25-165.us-west-2.compute.internal 
> named-pkcs11[3511]: GSSAPI client step 1Sep 20 06:37:00 
> ip-172-31-25-165.us-west-2.compute.internal named-pkcs11[3511]: GSSAPI Error: 
> Unspecified GSS failure.  Minor code may provide more information Sep 20 
> 06:37:00 ip-172-31-25-165.us-west-2.compute.internal named-pkcs11[3511]: LDAP 
> error: Local error: SASL(-1): generic failure: GSSAPI Error: Unspecified 
> GSSep 20 06:37:00 ip-172-31-25-165.us-west-2.compute.internal 
> named-pkcs11[3511]: couldn't establish connection in LDAP connection pool: 
> failureSep 20 06:37:00 ip-172-31-25-165.us-west-2.compute.internal 
> named-pkcs11[3511]: dynamic database 'ipa' configuration failed: failureSep 
> 20 06:37:00 ip-172-31-25-165.us-west-2.compute.internal named-pkcs11[3511]: 
> loading configuration: failureSep 20 06:37:00 
> ip-172-31-25-165.us-west-2.compute.internal named-pkcs11[3511]: exiting (due 
> to fatal error)Sep 20 06:37:00 ip-172-31-25-165.us-west-2.compute.internal 
> systemd[1]: named-pkcs11.service: control process exited, code=exited 
> status=1Sep 20 06:37:00 ip-172-31-25-165.us-west-2.compute.internal 
> systemd[1]: Failed to start Berkeley Internet Name Domain (DNS) with native 
> PKCS#11.-- Subject: Unit named-pkcs11.service has failed-- Defined-By: 
> systemd-- Support: 
>

[Freeipa-users] IPA Server is not coming backup

2016-09-20 Thread Deepak Dimri

Hi All,
My IPA Server was working all fine until i tried restarting it using "ipactl 
restart"  and now i am ended with these errors :( 








[root@ip-172-31-25-165 plugins]# ipactl restartStarting Directory 
ServiceRestarting krb5kdc ServiceRestarting kadmin ServiceStarting named 
ServiceJob for named-pkcs11.service failed because the control process exited 
with error code. See "systemctl status named-pkcs11.service" and "journalctl 
-xe" for details.Failed to start named ServiceShutting down















Aborting ipactl
This is what i get with  "systemctl status named-pkcs11.service"
[root@ip-172-31-25-165 plugins]# systemctl status named-pkcs11.service● 
named-pkcs11.service - Berkeley Internet Name Domain (DNS) with native PKCS#11  
 Loaded: loaded (/usr/lib/systemd/system/named-pkcs11.service; disabled; vendor 
preset: disabled)   Active: failed (Result: exit-code) since Tue 2016-09-20 
06:28:03 EDT; 1min 2s ago  Process: 3281 ExecStart=/usr/sbin/named-pkcs11 -u 
named $OPTIONS (code=exited, status=1/FAILURE)  Process: 3278 
ExecStartPre=/bin/bash -c if [ ! "$DISABLE_ZONE_CHECKING" == "yes" ]; then 
/usr/sbin/named-checkconf -z /etc/named.conf; else echo "Checking of zone files 
is disabled"; fi (code=exited, status=0/SUCCESS)
Sep 20 06:28:03 ip-172-31-25-165.us-west-2.compute.internal named-pkcs11[3284]: 
GSSAPI Error: Unspecified GSS failure.  Minor code may provide more information 
(Server krbtgt/US-WEST-2.C...database)Sep 20 06:28:03 
ip-172-31-25-165.us-west-2.compute.internal named-pkcs11[3284]: LDAP error: 
Local error: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure.  
Minor code may...er failedSep 20 06:28:03 
ip-172-31-25-165.us-west-2.compute.internal named-pkcs11[3284]: couldn't 
establish connection in LDAP connection pool: failureSep 20 06:28:03 
ip-172-31-25-165.us-west-2.compute.internal named-pkcs11[3284]: dynamic 
database 'ipa' configuration failed: failureSep 20 06:28:03 
ip-172-31-25-165.us-west-2.compute.internal named-pkcs11[3284]: loading 
configuration: failureSep 20 06:28:03 
ip-172-31-25-165.us-west-2.compute.internal named-pkcs11[3284]: exiting (due to 
fatal error)Sep 20 06:28:03 ip-172-31-25-165.us-west-2.compute.internal 
systemd[1]: named-pkcs11.service: control process exited, code=exited 
status=1Sep 20 06:28:03 ip-172-31-25-165.us-west-2.compute.internal systemd[1]: 
Failed to start Berkeley Internet Name Domain (DNS) with native PKCS#11.Sep 20 
06:28:03 ip-172-31-25-165.us-west-2.compute.internal systemd[1]: Unit 
named-pkcs11.service entered failed state.Sep 20 06:28:03 
ip-172-31-25-165.us-west-2.compute.internal systemd[1]: named-pkcs11.service 
failed.
























Hint: Some lines were ellipsized, use -l to show in full.
output from "journalctl -xe" is as below:
[root@ip-172-31-25-165 ec2-user]# journalctl -xeSep 20 06:37:00 
ip-172-31-25-165.us-west-2.compute.internal named-pkcs11[3511]: option 
'serial_autoincrement' is not supported, ignoringSep 20 06:37:00 
ip-172-31-25-165.us-west-2.compute.internal named-pkcs11[3511]: GSSAPI client 
step 1Sep 20 06:37:00 ip-172-31-25-165.us-west-2.compute.internal 
named-pkcs11[3511]: GSSAPI client step 1Sep 20 06:37:00 
ip-172-31-25-165.us-west-2.compute.internal named-pkcs11[3511]: GSSAPI Error: 
Unspecified GSS failure.  Minor code may provide more information Sep 20 
06:37:00 ip-172-31-25-165.us-west-2.compute.internal named-pkcs11[3511]: LDAP 
error: Local error: SASL(-1): generic failure: GSSAPI Error: Unspecified GSSep 
20 06:37:00 ip-172-31-25-165.us-west-2.compute.internal named-pkcs11[3511]: 
couldn't establish connection in LDAP connection pool: failureSep 20 06:37:00 
ip-172-31-25-165.us-west-2.compute.internal named-pkcs11[3511]: dynamic 
database 'ipa' configuration failed: failureSep 20 06:37:00 
ip-172-31-25-165.us-west-2.compute.internal named-pkcs11[3511]: loading 
configuration: failureSep 20 06:37:00 
ip-172-31-25-165.us-west-2.compute.internal named-pkcs11[3511]: exiting (due to 
fatal error)Sep 20 06:37:00 ip-172-31-25-165.us-west-2.compute.internal 
systemd[1]: named-pkcs11.service: control process exited, code=exited 
status=1Sep 20 06:37:00 ip-172-31-25-165.us-west-2.compute.internal systemd[1]: 
Failed to start Berkeley Internet Name Domain (DNS) with native PKCS#11.-- 
Subject: Unit named-pkcs11.service has failed-- Defined-By: systemd-- Support: 
http://lists.freedesktop.org/mailman/listinfo/systemd-devel-- -- Unit 
named-pkcs11.service has failed.-- -- The result is failed.Sep 20 06:37:00 
ip-172-31-25-165.us-west-2.compute.internal systemd[1]: Unit 
named-pkcs11.service entered failed state.Sep 20 06:37:00 
ip-172-31-25-165.us-west-2.compute.internal systemd[1]: named-pkcs11.service 
failed.Sep 20 06:37:00 ip-172-31-25-165.us-west-2.compute.internal 
polkitd[529]: Unregistered Authentication Agent for unix-process:3498:364279453 
(system bus name :1.Sep 20 06:37:00 ip-172-31-25-165.us-west-2.compute.internal 
polkitd[529]: Registered Authentication Agent

Re: [Freeipa-users] CA: Cannot add Centos7.2 replica to Centos6.8 ipa server [SOLVED]

2016-09-20 Thread Giorgos Kafataridis


On 09/19/2016 03:51 PM, Giorgos Kafataridis wrote:



On 09/16/2016 06:39 PM, Petr Vobornik wrote:

On 09/14/2016 07:26 PM, Giorgos Kafataridis wrote:


On 09/13/2016 10:36 PM, Endi Sukma Dewata wrote:

On 9/12/2016 9:35 PM, Endi Sukma Dewata wrote:

On 9/9/2016 2:46 PM, Georgios Kafataridis wrote:

I've tried that but still the same result.

[root@ipa-server /]# ldapsearch -D "cn=directory manager" -W -p 
389 -h

localhost -b "uid=admin,ou=people,o=ipaca"
Enter LDAP Password:
# extended LDIF
#
# LDAPv3
# base

Re: [Freeipa-users] certificates not renewing CA_UNREACHEABLE

2016-09-20 Thread Natxo Asenjo

On Mon, Sep 19, 2016 at 5:27 PM, Rob Crittenden  wrote:

> Natxo Asenjo wrote:
>
>> hi,
>>
>>
>> On Fri, Sep 16, 2016 at 4:22 PM, Rob Crittenden >
> Ok, how about we work around the problem.
>

Gladly ;-)


> Since it is failing on the revocation what you might try is removing the
> userCertificate value from the ldap/kdc01.unix.iriszorg.nl service entry.
>
> I think this will work:
>
> $ ipa service-show ldap/kdc01.unix.iriszorg.nl |grep Serial
> 
>
> $ ipa service-mod --certificate= ldap/kdc01.unix.iriszorg.nl
>
> If this doesn't work you can use ldapmodify to delete the usercertificate
> value.
>
> This will remove the certificate value so there is nothing to revoke and a
> new cert will be saved (hopefully).
>
> Now try to resubmit the request via certmonger.
>
> It if works then you can run ipa cert-revooke 
>
> It isn't a great answer long-term because it is really just working around
> the problem but it should get the certs renewed.
>
>
ok, so I restarted the httpd service then I could use ipa service-show:

$ ipa service-show ldap/kdc01.unix.iriszorg.nl |grep Serial
  Serial Number: 175
  Serial Number (hex): 0xAF
bash-4.1$ ipa service-mod --certificate= ldap/kdc01.unix.iriszorg.nl
---
Modified service "ldap/kdc01.unix.iriszorg...@unix.iriszorg.nl"
---
  Principal: ldap/kdc01.unix.iriszorg...@unix.iriszorg.nl
  Managed by: kdc01.unix.iriszorg.nl


bash-4.1$ sudo ipa-getcert resubmit -i
20121107212513   Resubmitting "20121107212513" to
"IPA".
bash-4.1$ sudo getcert list
Number of certificates and requests being tracked: 8.
Request ID '20121107212513':
status: CA_UNREACHABLE
ca-error: Server failed request, will retry: 4301 (RPC failed at
server.  Certificate operation cannot be completed: Failure decoding
Certificate Signing Request).
stuck: yes
key pair storage:
type=NSSDB,location='/etc/dirsrv/slapd-UNIX-IRISZORG-NL',nickname='Server-Cert',token='NSS
Certificate DB',pinfile='/etc/dirsrv/slapd-UNIX-IRISZORG-NL/pwdfile.txt'
certificate:
type=NSSDB,location='/etc/dirsrv/slapd-UNIX-IRISZORG-NL',nickname='Server-Cert',token='NSS
Certificate DB'
CA: IPA
issuer: CN=Certificate Authority,O=UNIX.IRISZORG.NL
subject: CN=kdc01.unix.iriszorg.nl,O=UNIX.IRISZORG.NL
expires: 2016-10-12 10:49:24 UTC
eku: id-kp-serverAuth,id-kp-clientAuth
pre-save command:
post-save command: /usr/lib/ipa/certmonger/restart_dirsrv
UNIX-IRISZORG-NL
track: yes
auto-renew: yes



the certificate is gone:
$ ipa service-show ldap/kdc01.unix.iriszorg.nl
ipa: ERROR: Could not create log_dir u'/home/jose.admin/.ipa/log'
  Principal: ldap/kdc01.unix.iriszorg...@unix.iriszorg.nl
  Keytab: True
  Managed by: kdc01.unix.iriszorg.nl


But then I thought, what the hell, let's try again, restarted httpd,
resubmitted it, and now it did work ;-)

$ ipa service-show ldap/kdc01.unix.iriszorg.nl
  Principal: ldap/kdc01.unix.iriszorg...@unix.iriszorg.nl
  Certificate:
MIIDrDCCApSgAwIBAgICAPUwDQYJKoZIhvcNAQELBQAwOzEZMBcGA1UEChMQVU5JWC5JUklTWk9SRy5OTDEeMBwGA1UEAxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTE2MDkyMDA4MDY1OFoXDTE4MDkyMTA4MDY1OFowPDEZMBcGA1UEChMQVU5JWC5JUklTWk9SRy5OTDEfMB0GA1UEAxMWa2RjMDEudW5peC5pcmlzem9yZy5ubDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAO2QVqrFRb/Q5dhkAi7BK29BJhqTvbaH3bNDLvhe1snyChdlr/AIwrJj/53Ti2eJ7u1BtV7u3gSwQ3/xJ0HwUZmOEQHCNDrjcGy+iw7lqkC5NaZ8AGt8bSTGWwnJvEGWrb3uEJzVZf+xB5eZa8vFXr+Jlcfoq8DbVZhX274pmpVfQOnRckD+AmncuEItHpcJCCHneF0QzA5DQqlTPUFerFm3F/iI/k6g9XbHQaNejcUYdhXpy9q0mEuBIIsEzTeNWTTEsUYX5TPVEsN3x2feA0icxR6bUTeg2BqSu7ZOuM55iBp3l0d9UAQ7W7yh76FI/Bqz8vIMdS6VsurPS4asLa8CAwEAAaOBuDCBtTAfBgNVHSMEGDAWgBSjl+SKLrjPPuoz8ryT1iPeqYQ2aDBEBggrBgEFBQcBAQQ4MDYwNAYIKwYBBQUHMAGGKGh0dHA6Ly9rZGMwMS51bml4LmlyaXN6b3JnLm5sOjgwL2NhL29jc3AwDgYDVR0PAQH/BAQDAgTwMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjAdBgNVHQ4EFgQUBIRsG98GBkIyB/BgQKloUlLEJeEwDQYJKoZIhvcNAQELBQADggEBAHN+ggklVf2uzaePwEI9rMObe0WZeOyCLZxEtigDaJIHkq3GzkugxcG8ivD/LnuF0D8m07npfpIMC3QRUJQjFjz6E3rKtqau0QY0BO+Dwg1TzItQqXxgHtCqcQ7bmahj2AMPRNUXeZck0p/eueG4wj2kbLwTLU6cOfwnT4IOfszAS9GCql6oQIXlOfG6i6DAodBpgWziDfIrRJsJi4ZE+FvJL/ImJDdW+En50UyGp0n31oMSDIxWf1bdWUctSEYhcy9JftzkitNm1FD+a1HzeYyuHthzlHHcSIXN/kXRSGktpe8VHE5XLtKnH92vmkMnyxZvE///2+ExHXIAOkwq3ck=
  Keytab: True
  Managed by: kdc01.unix.iriszorg.nl
  Subject: CN=kdc01.unix.iriszorg.nl,O=UNIX.IRISZORG.NL
  Serial Number: 245
  Serial Number (hex): 0xF5
  Issuer: CN=Certificate Authority,O=UNIX.IRISZORG.NL
  Not Before: Tue Sep 20 08:06:58 2016 UTC
  Not After: Fri Sep 21 08:06:58 2018 UTC
  Fingerprint (MD5): f8:d3:cb:6f:4c:ca:e4:f3:47:65:51:d3:2c:69:84:df
  Fingerprint (SHA1):
e3:0a:66:19:d7:36:fe:c4:ff:58:bf:90:35:3e:0b:31:cb:a0:58:37

So I could revoke the old one:

$ ipa cert-revoke 175
  Revoked: True


and now getcert list shows the certificate

Re: [Freeipa-users] In webgui, ID Views slow, to crashingly slow

2016-09-20 Thread Lachlan Musicman

I concede - FreeIPA is big and hard and I am new. Evidence would suggest
that you know exactly what's going on under the hood. :)

Thanks everyone.

--
The most dangerous phrase in the language is, "We've always done it this
way."

- Grace Hopper

On 20 September 2016 at 18:10, Alexander Bokovoy 
wrote:

> On Tue, 20 Sep 2016, Sumit Bose wrote:
>
>> On Tue, Sep 20, 2016 at 09:33:21AM +0300, Alexander Bokovoy wrote:
>>
>>> On Tue, 20 Sep 2016, Martin Babinsky wrote:
>>> > On 09/20/2016 12:17 AM, Simpson Lachlan wrote:
>>> > > > -Original Message-
>>> > > >
>>> > > > On 09/19/2016 03:12 AM, Lachlan Musicman wrote:
>>> > > > > Hi
>>> > > > >
>>> > > > > Sometimes when I visit the ID Views page in the webgui, it is
>>> > > > > crushingly slow, and often it times out.
>>> > > > >
>>> > > > > Centos 7, ipa --version
>>> > > > > VERSION: 4.2.0, API_VERSION: 2.156
>>> > > > >
>>> > > > > Is there a reason, can I do something to fix this?
>>> > > > >
>>> > > >
>>> > > > What kind of ID Views do you use? Do you use them to  override AD
>>> users?
>>> > > > Is there any useful info in '/var/log/httpd/error_log'?
>>> > >
>>> > > There is the single ID View Name, Default Trust View, and in that we
>>> have a number of users over riding the AD usernames and home dirs.
>>> > >
>>> > > The httpd error log is relatively large, tbh, but there's nothing in
>>> there that looks like an obvious reason. In fact, for an error log, there
>>> is a hell of a lot of "SUCCESS" messages? The most obvious culprit in the
>>> error log is jsonserver_session...
>>> > >
>>> > > Next time I see it (I only see it intermittently), I'll grab the
>>> logs and have a look.
>>> > >
>>> > > Cheers
>>> > > L.
>>> > >
>>> > >
>>> > >
>>> > > This email (including any attachments or links) may contain
>>> > > confidential and/or legally privileged information and is
>>> > > intended only to be read or used by the addressee.  If you
>>> > > are not the intended addressee, any use, distribution,
>>> > > disclosure or copying of this email is strictly
>>> > > prohibited.
>>> > > Confidentiality and legal privilege attached to this email
>>> > > (including any attachments) are not waived or lost by
>>> > > reason of its mistaken delivery to you.
>>> > > If you have received this email in error, please delete it
>>> > > and notify us immediately by telephone or email.  Peter
>>> > > MacCallum Cancer Centre provides no guarantee that this
>>> > > transmission is free of virus or that it has not been
>>> > > intercepted or altered and will not be liable for any delay
>>> > > in its receipt.
>>> > >
>>> >
>>> > One thing that crossed my mind is to check the connectivity to the AD
>>> > domain controllers. To resolve AD user overrides, FreeIPA uses SSSD to
>>> > contact AD DCs to do the username -> SID translation. If there is some
>>> > problem contacting them, then there may be hangs/timeouts when
>>> resolving
>>> > override anchors.
>>> Internally IPA framework attempts to resolve ID override anchors. We can
>>> actually optimize this code as ipaOriginalUID attribute contains
>>> normalized name already, written their when the override is created and
>>> never changed afterwards. This should speed up the resolution of large
>>> overrides.
>>>
>>> Martin, can you file a ticket for that? The code in question is
>>> baseidoverride.convert_anchor_to_human_readable_form() which could
>>> benefit from passing in entry_attrs and checking ipaoriginaluid there.
>>> If 'ipaoriginaluid' is missing, do analysis of ipaanchoruuid like it is
>>> done now.
>>>
>>
>> As an alternative I wonder if the WebUI can be made asynchronous in the
>> sense that it displays the raw data (the SID in this case) first and run
>> the lookups in the background and replace the SID when the name is
>> available. I've seen some Windows tools behaving this when looking up
>> large numbers of SIDs.
>>
> We have that for external group members already.
>
> However, in the ID overrides there is no SID as it is. The RDN of the ID
> override is 'ipaAnchorUUID' attribute which is an encoding of a target
> reference. We don't need to resolve it because we already have it
> resolved in 'ipaOriginalUid' attribute -- this was done to help Schema
> Compatibility and SASL mapping plugins which cannot resolve
> ipaAnchorUUID value. We just need to make its use consistent across the
> IPA framework.
>
>
> --
> / Alexander Bokovoy
>
> --
> Manage your subscription for the Freeipa-users mailing list:
> https://www.redhat.com/mailman/listinfo/freeipa-users
> Go to http://freeipa.org for more info on the project
>
-- 
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] In webgui, ID Views slow, to crashingly slow

2016-09-20 Thread Alexander Bokovoy


On Tue, 20 Sep 2016, Lachlan Musicman wrote:

I've actually seen that on occasion - when it's loading sometimes that
happens already?

For external group members -- yes, not for ID overrides.
See my other answer.

--
/ Alexander Bokovoy

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

Re: [Freeipa-users] In webgui, ID Views slow, to crashingly slow

2016-09-20 Thread Alexander Bokovoy


On Tue, 20 Sep 2016, Sumit Bose wrote:

On Tue, Sep 20, 2016 at 09:33:21AM +0300, Alexander Bokovoy wrote:

On Tue, 20 Sep 2016, Martin Babinsky wrote:
> On 09/20/2016 12:17 AM, Simpson Lachlan wrote:
> > > -Original Message-
> > >
> > > On 09/19/2016 03:12 AM, Lachlan Musicman wrote:
> > > > Hi
> > > >
> > > > Sometimes when I visit the ID Views page in the webgui, it is
> > > > crushingly slow, and often it times out.
> > > >
> > > > Centos 7, ipa --version
> > > > VERSION: 4.2.0, API_VERSION: 2.156
> > > >
> > > > Is there a reason, can I do something to fix this?
> > > >
> > >
> > > What kind of ID Views do you use? Do you use them to  override AD users?
> > > Is there any useful info in '/var/log/httpd/error_log'?
> >
> > There is the single ID View Name, Default Trust View, and in that we have a 
number of users over riding the AD usernames and home dirs.
> >
> > The httpd error log is relatively large, tbh, but there's nothing in there that looks 
like an obvious reason. In fact, for an error log, there is a hell of a lot of 
"SUCCESS" messages? The most obvious culprit in the error log is jsonserver_session...
> >
> > Next time I see it (I only see it intermittently), I'll grab the logs and 
have a look.
> >
> > Cheers
> > L.
> >
> >
> >
> > This email (including any attachments or links) may contain
> > confidential and/or legally privileged information and is
> > intended only to be read or used by the addressee.  If you
> > are not the intended addressee, any use, distribution,
> > disclosure or copying of this email is strictly
> > prohibited.
> > Confidentiality and legal privilege attached to this email
> > (including any attachments) are not waived or lost by
> > reason of its mistaken delivery to you.
> > If you have received this email in error, please delete it
> > and notify us immediately by telephone or email.  Peter
> > MacCallum Cancer Centre provides no guarantee that this
> > transmission is free of virus or that it has not been
> > intercepted or altered and will not be liable for any delay
> > in its receipt.
> >
>
> One thing that crossed my mind is to check the connectivity to the AD
> domain controllers. To resolve AD user overrides, FreeIPA uses SSSD to
> contact AD DCs to do the username -> SID translation. If there is some
> problem contacting them, then there may be hangs/timeouts when resolving
> override anchors.
Internally IPA framework attempts to resolve ID override anchors. We can
actually optimize this code as ipaOriginalUID attribute contains
normalized name already, written their when the override is created and
never changed afterwards. This should speed up the resolution of large
overrides.

Martin, can you file a ticket for that? The code in question is
baseidoverride.convert_anchor_to_human_readable_form() which could
benefit from passing in entry_attrs and checking ipaoriginaluid there.
If 'ipaoriginaluid' is missing, do analysis of ipaanchoruuid like it is
done now.


As an alternative I wonder if the WebUI can be made asynchronous in the
sense that it displays the raw data (the SID in this case) first and run
the lookups in the background and replace the SID when the name is
available. I've seen some Windows tools behaving this when looking up
large numbers of SIDs.

We have that for external group members already.

However, in the ID overrides there is no SID as it is. The RDN of the ID
override is 'ipaAnchorUUID' attribute which is an encoding of a target
reference. We don't need to resolve it because we already have it
resolved in 'ipaOriginalUid' attribute -- this was done to help Schema
Compatibility and SASL mapping plugins which cannot resolve
ipaAnchorUUID value. We just need to make its use consistent across the
IPA framework.

--
/ Alexander Bokovoy

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

Re: [Freeipa-users] In webgui, ID Views slow, to crashingly slow

2016-09-20 Thread Lachlan Musicman

I've actually seen that on occasion - when it's loading sometimes that
happens already?

--
The most dangerous phrase in the language is, "We've always done it this
way."

- Grace Hopper

On 20 September 2016 at 17:49, Sumit Bose  wrote:

> On Tue, Sep 20, 2016 at 09:33:21AM +0300, Alexander Bokovoy wrote:
> > On Tue, 20 Sep 2016, Martin Babinsky wrote:
> > > On 09/20/2016 12:17 AM, Simpson Lachlan wrote:
> > > > > -Original Message-
> > > > >
> > > > > On 09/19/2016 03:12 AM, Lachlan Musicman wrote:
> > > > > > Hi
> > > > > >
> > > > > > Sometimes when I visit the ID Views page in the webgui, it is
> > > > > > crushingly slow, and often it times out.
> > > > > >
> > > > > > Centos 7, ipa --version
> > > > > > VERSION: 4.2.0, API_VERSION: 2.156
> > > > > >
> > > > > > Is there a reason, can I do something to fix this?
> > > > > >
> > > > >
> > > > > What kind of ID Views do you use? Do you use them to  override AD
> users?
> > > > > Is there any useful info in '/var/log/httpd/error_log'?
> > > >
> > > > There is the single ID View Name, Default Trust View, and in that we
> have a number of users over riding the AD usernames and home dirs.
> > > >
> > > > The httpd error log is relatively large, tbh, but there's nothing in
> there that looks like an obvious reason. In fact, for an error log, there
> is a hell of a lot of "SUCCESS" messages? The most obvious culprit in the
> error log is jsonserver_session...
> > > >
> > > > Next time I see it (I only see it intermittently), I'll grab the
> logs and have a look.
> > > >
> > > > Cheers
> > > > L.
> > > >
> > > >
> > > >
> > > > This email (including any attachments or links) may contain
> > > > confidential and/or legally privileged information and is
> > > > intended only to be read or used by the addressee.  If you
> > > > are not the intended addressee, any use, distribution,
> > > > disclosure or copying of this email is strictly
> > > > prohibited.
> > > > Confidentiality and legal privilege attached to this email
> > > > (including any attachments) are not waived or lost by
> > > > reason of its mistaken delivery to you.
> > > > If you have received this email in error, please delete it
> > > > and notify us immediately by telephone or email.  Peter
> > > > MacCallum Cancer Centre provides no guarantee that this
> > > > transmission is free of virus or that it has not been
> > > > intercepted or altered and will not be liable for any delay
> > > > in its receipt.
> > > >
> > >
> > > One thing that crossed my mind is to check the connectivity to the AD
> > > domain controllers. To resolve AD user overrides, FreeIPA uses SSSD to
> > > contact AD DCs to do the username -> SID translation. If there is some
> > > problem contacting them, then there may be hangs/timeouts when
> resolving
> > > override anchors.
> > Internally IPA framework attempts to resolve ID override anchors. We can
> > actually optimize this code as ipaOriginalUID attribute contains
> > normalized name already, written their when the override is created and
> > never changed afterwards. This should speed up the resolution of large
> > overrides.
> >
> > Martin, can you file a ticket for that? The code in question is
> > baseidoverride.convert_anchor_to_human_readable_form() which could
> > benefit from passing in entry_attrs and checking ipaoriginaluid there.
> > If 'ipaoriginaluid' is missing, do analysis of ipaanchoruuid like it is
> > done now.
>
> As an alternative I wonder if the WebUI can be made asynchronous in the
> sense that it displays the raw data (the SID in this case) first and run
> the lookups in the background and replace the SID when the name is
> available. I've seen some Windows tools behaving this when looking up
> large numbers of SIDs.
>
> bye,
> Sumit
>
> >
> > --
> > / Alexander Bokovoy
> >
> > --
> > Manage your subscription for the Freeipa-users mailing list:
> > https://www.redhat.com/mailman/listinfo/freeipa-users
> > Go to http://freeipa.org for more info on the project
>
> --
> 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] In webgui, ID Views slow, to crashingly slow

2016-09-20 Thread Martin Babinsky


On 09/20/2016 08:33 AM, Alexander Bokovoy wrote:

On Tue, 20 Sep 2016, Martin Babinsky wrote:

On 09/20/2016 12:17 AM, Simpson Lachlan wrote:

-Original Message-

On 09/19/2016 03:12 AM, Lachlan Musicman wrote:

Hi

Sometimes when I visit the ID Views page in the webgui, it is
crushingly slow, and often it times out.

Centos 7, ipa --version
VERSION: 4.2.0, API_VERSION: 2.156

Is there a reason, can I do something to fix this?



What kind of ID Views do you use? Do you use them to  override AD
users?
Is there any useful info in '/var/log/httpd/error_log'?


There is the single ID View Name, Default Trust View, and in that we
have a number of users over riding the AD usernames and home dirs.

The httpd error log is relatively large, tbh, but there's nothing in
there that looks like an obvious reason. In fact, for an error log,
there is a hell of a lot of "SUCCESS" messages? The most obvious
culprit in the error log is jsonserver_session...

Next time I see it (I only see it intermittently), I'll grab the logs
and have a look.

Cheers
L.



This email (including any attachments or links) may contain
confidential and/or legally privileged information and is
intended only to be read or used by the addressee.  If you
are not the intended addressee, any use, distribution,
disclosure or copying of this email is strictly
prohibited.
Confidentiality and legal privilege attached to this email
(including any attachments) are not waived or lost by
reason of its mistaken delivery to you.
If you have received this email in error, please delete it
and notify us immediately by telephone or email.  Peter
MacCallum Cancer Centre provides no guarantee that this
transmission is free of virus or that it has not been
intercepted or altered and will not be liable for any delay
in its receipt.



One thing that crossed my mind is to check the connectivity to the AD
domain controllers. To resolve AD user overrides, FreeIPA uses SSSD to
contact AD DCs to do the username -> SID translation. If there is some
problem contacting them, then there may be hangs/timeouts when
resolving override anchors.

Internally IPA framework attempts to resolve ID override anchors. We can
actually optimize this code as ipaOriginalUID attribute contains
normalized name already, written their when the override is created and
never changed afterwards. This should speed up the resolution of large
overrides.

Martin, can you file a ticket for that? The code in question is
baseidoverride.convert_anchor_to_human_readable_form() which could
benefit from passing in entry_attrs and checking ipaoriginaluid there.
If 'ipaoriginaluid' is missing, do analysis of ipaanchoruuid like it is
done now.



Done: https://fedorahosted.org/freeipa/ticket/6339

--
Martin^3 Babinsky

--
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] In webgui, ID Views slow, to crashingly slow

2016-09-20 Thread Sumit Bose

On Tue, Sep 20, 2016 at 09:33:21AM +0300, Alexander Bokovoy wrote:
> On Tue, 20 Sep 2016, Martin Babinsky wrote:
> > On 09/20/2016 12:17 AM, Simpson Lachlan wrote:
> > > > -Original Message-
> > > > 
> > > > On 09/19/2016 03:12 AM, Lachlan Musicman wrote:
> > > > > Hi
> > > > > 
> > > > > Sometimes when I visit the ID Views page in the webgui, it is
> > > > > crushingly slow, and often it times out.
> > > > > 
> > > > > Centos 7, ipa --version
> > > > > VERSION: 4.2.0, API_VERSION: 2.156
> > > > > 
> > > > > Is there a reason, can I do something to fix this?
> > > > > 
> > > > 
> > > > What kind of ID Views do you use? Do you use them to  override AD users?
> > > > Is there any useful info in '/var/log/httpd/error_log'?
> > > 
> > > There is the single ID View Name, Default Trust View, and in that we have 
> > > a number of users over riding the AD usernames and home dirs.
> > > 
> > > The httpd error log is relatively large, tbh, but there's nothing in 
> > > there that looks like an obvious reason. In fact, for an error log, there 
> > > is a hell of a lot of "SUCCESS" messages? The most obvious culprit in the 
> > > error log is jsonserver_session...
> > > 
> > > Next time I see it (I only see it intermittently), I'll grab the logs and 
> > > have a look.
> > > 
> > > Cheers
> > > L.
> > > 
> > > 
> > > 
> > > This email (including any attachments or links) may contain
> > > confidential and/or legally privileged information and is
> > > intended only to be read or used by the addressee.  If you
> > > are not the intended addressee, any use, distribution,
> > > disclosure or copying of this email is strictly
> > > prohibited.
> > > Confidentiality and legal privilege attached to this email
> > > (including any attachments) are not waived or lost by
> > > reason of its mistaken delivery to you.
> > > If you have received this email in error, please delete it
> > > and notify us immediately by telephone or email.  Peter
> > > MacCallum Cancer Centre provides no guarantee that this
> > > transmission is free of virus or that it has not been
> > > intercepted or altered and will not be liable for any delay
> > > in its receipt.
> > > 
> > 
> > One thing that crossed my mind is to check the connectivity to the AD
> > domain controllers. To resolve AD user overrides, FreeIPA uses SSSD to
> > contact AD DCs to do the username -> SID translation. If there is some
> > problem contacting them, then there may be hangs/timeouts when resolving
> > override anchors.
> Internally IPA framework attempts to resolve ID override anchors. We can
> actually optimize this code as ipaOriginalUID attribute contains
> normalized name already, written their when the override is created and
> never changed afterwards. This should speed up the resolution of large
> overrides.
> 
> Martin, can you file a ticket for that? The code in question is
> baseidoverride.convert_anchor_to_human_readable_form() which could
> benefit from passing in entry_attrs and checking ipaoriginaluid there.
> If 'ipaoriginaluid' is missing, do analysis of ipaanchoruuid like it is
> done now.

As an alternative I wonder if the WebUI can be made asynchronous in the
sense that it displays the raw data (the SID in this case) first and run
the lookups in the background and replace the SID when the name is
available. I've seen some Windows tools behaving this when looking up
large numbers of SIDs.

bye,
Sumit

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

-- 
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] Fwd: Re: Increase ListenBacklog for httpd

2016-09-20 Thread Rakesh Rajasekharan

Thanks Robbie for the inputs.. the load should not have been high as I have
around 4000 clients with 160 users which should be manageable

However, I saw a lot of clock skew too great errors in my krb5kdc.log...
however I haven't been able to verify if those were genuine...

Can too many clock skew errors take down the kerberos service..

On Mon, Sep 19, 2016 at 10:15 PM, Robbie Harwood 
wrote:

> Rakesh Rajasekharan  writes:
>
> > On Mon, Sep 12, 2016 at 10:13 AM, Rakesh Rajasekharan
> > >
> > wrote:
> >
> > sorry I guess I did not put the question correctly
> >
> > I wanted to know .. like we have the ListenBacklog for apache to
> > basically define the number of connections it can handle.. do we
> > have some thing similar for our krb5kdc service.. as the SYN floodin
> > at 88 looks like krb5kdc service is not able to handle sudden spurt
> > in connections or the number of connections are more than it could
> > handle..
> >
> > So, would be great if I could know how many connection it can
> > support at any given time ..most of the times I see this error while
> > i add clients to IPA master.. so if thers a known limit , I could
> > first check netstat to see how many connections I have at any point
> > and if its below the limit only then setup ipa-client-install
>
> We intentionally do not have such a parameter in krb5.  We call
> listen(5) internally, but please note this is probably not the parameter
> you want to be able to tune.
>
> The listen() backlog is the number of connections that are waiting to be
> accept()ed by the process.  They sit in the kernel, not receiving
> SYNACK.  This number does not count connections that the process - here
> krb5kdc - has accept()ed and is currently processing.
>
> If you're truly seeing connections faster than they can be accept()ed,
> you have a load problem that tuning this parameter likely won't fix.
> You should probably configure replicas: krb5 will fall back if the
> connection is refused from one kdc to the next configured one.  This
> will result in faster operation for your users than waiting on an
> enormous listen() backlog will as well.
>
> A tunable for the listen value may be added in the future, but is not
> available at the present time.
>
-- 
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] Issues with FreeIPA SSH Key authentication

2016-09-20 Thread Venkataramana Kintali

Thank you Lukas.
The issue , not being able to login to some servers in our setup with ssh
keys, was due to incorrect permissions on /usr directory,per the following
entry in /var/log/secure.

*sshd[12856]: error: bad ownership or modes for AuthorizedKeysCommand path
component "/usr"*

After setting up the permissions for /usr to 755, I was able to login to
these servers with ssh private keys.

Thank you again,Lukas, for your help.

Regards
Venkataramana






On Fri, Sep 16, 2016 at 11:51 AM, Lukas Slebodnik 
wrote:

> On (15/09/16 11:46), Venkataramana Kintali wrote:
> >Hi Lukas,
> >ssh_config is also same on all servers.
> >Our need is to do it both  ways, to be able to login with ssh public
> >keys(uploaded in IPA) and disable password login, and be able to access
> >allhosts within the same IPA domain silently from any host.
> >Hoping the configs will help, I am including the configurations here.
> >
> >ssh_config file :  http://pastebin.com/MWHyH1Qw
> >sshd_config file: http://pastebin.com/gpn5XhXM
> >sssd_config file: http://pastebin.com/5Pby6xKp
> >
> Looks good to me
>
> >I just used some placeholders for sssd_config file in pastebin instead of
> >actual values.
> >
>
> In initial mail you wrote:
> >I am able to login to some IPA clients but not able to login to other IPA
> >clients with putty using private key and passphrase.
> Therefore your previous test case is wrong.
> If you want to test authentication with public keys
> then you cannot obtain krb5 ticket with kinit.
>
> I would also recommend to call kdestory before
> authentication with ssh to be sure that gssapi
> authentication will not be used.
>
> I would recomment to set "debug_level = 7" in domain and ssh section
> on the server where you woudl like to authenticate.
> then restart sssd and try to authenticate with ssh + verbose mode
> e.g. ssh -v u...@remote.host
>
> Then I would recommend to compare logs from working server
> and from broken server.
>
> LS
>
-- 
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] bind crashes on rndc reload

2016-09-20 Thread Petr Spacek

On 20.9.2016 00:33, Anthony Joseph Messina wrote:
> On Monday, September 19, 2016 2:16:55 PM CDT Petr Spacek wrote:
>> On 12.9.2016 11:55, Anthony Joseph Messina wrote:
>>> On Monday, September 12, 2016 10:31:10 AM CDT Jochen Demmer wrote:
 Hi,

 I have a major issue with my setup:
 Fedora 24
 freeipa-common-4.3.2-2.fc24.noarch
 freeipa-admintools-4.3.2-2.fc24.noarch
 freeipa-server-dns-4.3.2-2.fc24.noarch
 freeipa-client-common-4.3.2-2.fc24.noarch
 freeipa-server-4.3.2-2.fc24.x86_64
 freeipa-server-common-4.3.2-2.fc24.noarch
 freeipa-client-4.3.2-2.fc24.x86_64
 bind-dyndb-ldap-9.0-3.fc24.x86_64
 bind-libs-lite-9.10.4-1.P2.fc24.x86_64
 bind-pkcs11-libs-9.10.4-1.P2.fc24.x86_64
 bind99-libs-9.9.9-1.P2.fc24.x86_64
 bind-utils-9.10.4-1.P2.fc24.x86_64
 rpcbind-0.2.3-11.rc1.fc24.x86_64
 bind-license-9.10.4-1.P2.fc24.noarch
 bind-pkcs11-9.10.4-1.P2.fc24.x86_64
 bind-9.10.4-1.P2.fc24.x86_64
 bind-libs-9.10.4-1.P2.fc24.x86_64
 bind99-license-9.9.9-1.P2.fc24.noarch
 bind-pkcs11-utils-9.10.4-1.P2.fc24.x86_64

 It seems that there is a regular but not daily "rndc reload" sent to the
 nameserver that leads to a crash of it. I sent a SIGHUP to the named
 process, but that didn't lead to a crash. Only "rndc reload" does. It
 does not crash EVERY time, but most of the times. I need to do an
 "ipactl restart" in order to get the nameserver up and running again.

 I found this thread, but this doesn't give me any clues:
 https://www.redhat.com/archives/freeipa-users/2012-May/msg00340.html

 This is what the log says:
 http://paste.debian.net/818354/
 Please understand that I obfuscated my IP addresses and domain names

 This is the strace:
 http://paste.debian.net/818365/

 This is my named.conf:
 http://paste.debian.net/818368/

 Hope someone can help.
 Jochen
>>>
>>> I wish I could, as I have the same issue, usually early Sunday morning
>>> after some cron/timer job that reloads:
>>>
>>> https://bugzilla.redhat.com/show_bug.cgi?id=1362162
>>
>> Could you please try bind-dyndb-ldap-10.1-1.fc24 from updates-testing?
>>
>> Alternatively the package can be downloaded from
>> http://koji.fedoraproject.org/koji/buildinfo?buildID=792505
>>
>> Please let me know if it fixes your problem or not.
> 
> bind-dyndb-ldap-10.1-1.fc24 from updates-testing seems to work, or at least 
> is 
> does not crash on rndc reload. I'll give it some time and see what happens, 
> since it didn't crash every time before either.  Thank you Petr.  -A

Thanks, I will be waiting for your observations!

-- 
Petr^2 Spacek

-- 
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] In webgui, ID Views slow, to crashingly slow

2016-09-20 Thread Alexander Bokovoy


On Tue, 20 Sep 2016, Martin Babinsky wrote:

On 09/20/2016 12:17 AM, Simpson Lachlan wrote:

-Original Message-

On 09/19/2016 03:12 AM, Lachlan Musicman wrote:

Hi

Sometimes when I visit the ID Views page in the webgui, it is
crushingly slow, and often it times out.

Centos 7, ipa --version
VERSION: 4.2.0, API_VERSION: 2.156

Is there a reason, can I do something to fix this?



What kind of ID Views do you use? Do you use them to  override AD users?
Is there any useful info in '/var/log/httpd/error_log'?


There is the single ID View Name, Default Trust View, and in that we have a 
number of users over riding the AD usernames and home dirs.

The httpd error log is relatively large, tbh, but there's nothing in there that looks 
like an obvious reason. In fact, for an error log, there is a hell of a lot of 
"SUCCESS" messages? The most obvious culprit in the error log is 
jsonserver_session...

Next time I see it (I only see it intermittently), I'll grab the logs and have 
a look.

Cheers
L.



This email (including any attachments or links) may contain
confidential and/or legally privileged information and is
intended only to be read or used by the addressee.  If you
are not the intended addressee, any use, distribution,
disclosure or copying of this email is strictly
prohibited.
Confidentiality and legal privilege attached to this email
(including any attachments) are not waived or lost by
reason of its mistaken delivery to you.
If you have received this email in error, please delete it
and notify us immediately by telephone or email.  Peter
MacCallum Cancer Centre provides no guarantee that this
transmission is free of virus or that it has not been
intercepted or altered and will not be liable for any delay
in its receipt.



One thing that crossed my mind is to check the connectivity to the AD 
domain controllers. To resolve AD user overrides, FreeIPA uses SSSD to 
contact AD DCs to do the username -> SID translation. If there is some 
problem contacting them, then there may be hangs/timeouts when 
resolving override anchors.

Internally IPA framework attempts to resolve ID override anchors. We can
actually optimize this code as ipaOriginalUID attribute contains
normalized name already, written their when the override is created and
never changed afterwards. This should speed up the resolution of large
overrides.

Martin, can you file a ticket for that? The code in question is
baseidoverride.convert_anchor_to_human_readable_form() which could
benefit from passing in entry_attrs and checking ipaoriginaluid there.
If 'ipaoriginaluid' is missing, do analysis of ipaanchoruuid like it is
done now.

--
/ Alexander Bokovoy

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

[Freeipa-users] Me Again

Re: [Freeipa-users] login auth fails then success

Re: [Freeipa-users] login auth fails then success

Re: [Freeipa-users] certificates not renewing CA_UNREACHEABLE

Re: [Freeipa-users] 3rd party Cert install now IPA total broken

[Freeipa-users] IPA Server is not coming backup

Re: [Freeipa-users] IPA Server is not coming backup

[Freeipa-users] IPA Server is not coming backup

Re: [Freeipa-users] CA: Cannot add Centos7.2 replica to Centos6.8 ipa server [SOLVED]

Re: [Freeipa-users] certificates not renewing CA_UNREACHEABLE

Re: [Freeipa-users] In webgui, ID Views slow, to crashingly slow

Re: [Freeipa-users] In webgui, ID Views slow, to crashingly slow

Re: [Freeipa-users] In webgui, ID Views slow, to crashingly slow

Re: [Freeipa-users] In webgui, ID Views slow, to crashingly slow

Re: [Freeipa-users] In webgui, ID Views slow, to crashingly slow

Re: [Freeipa-users] In webgui, ID Views slow, to crashingly slow

Re: [Freeipa-users] Fwd: Re: Increase ListenBacklog for httpd

Re: [Freeipa-users] Issues with FreeIPA SSH Key authentication

Re: [Freeipa-users] bind crashes on rndc reload

Re: [Freeipa-users] In webgui, ID Views slow, to crashingly slow

20 matches

Site Navigation

Mail list logo

Footer information