[Freeipa-users] Re: Fwd: [389-users] How to invalidate local cache after user changed their password

[Sumit Bose via FreeIPA-users]

On Wed, Feb 27, 2019 at 03:28:08PM -0500, Mark Reynolds via FreeIPA-users wrote:
> Forwarding to freeipa-users who have more knowledge on SSSD
> 
> 
> 
>  Forwarded Message 
> Subject:  [389-users] How to invalidate local cache after user changed 
> their
> password
> Date: Wed, 27 Feb 2019 19:22:19 + (UTC)
> From: xinhuan zheng 
> Reply-To: General discussion list for the 389 Directory server project.
> <389-us...@lists.fedoraproject.org>
> To:   389-us...@lists.fedoraproject.org
> 
> 
> 
> Hello,
> 
> I have been struggling with this problem for a while. When a user changed
> their password, our 389 directory servers received new password and saved
> into directory server. However, when user tries to login to a server whose
> authentication is using 389 directory server, their new password won't work
> for the first few minutes. There is a local cache process, sssd, running on
> the server the user tries to login. Apparently sssd is still using old
> password information, and does not know password has changed on directory
> servers. I have set sssd to keep cache information for 5 minutes only, and
> do pre-fetch prior to cache information expiring. But I don't know how to
> tell sssd to ignore cache completely when information has changed on 389
> directory server side.
> 
> Is there a way to completely disable sssd local cache, and only use it when
> 389 directory servers are not available?

If SSSD stores a hashed version of the password in it cache or not is
controlled by the cache_credentials option in the [domain/...] section
of sssd.conf. The default is 'false' I assume you have set it to 'true',
see man sssd.conf for details.

But please note that SSSD only uses the cache password if the backend is
offline, i.e. SSSD thinks it cannot reach any servers. You can check
with 'sssctl domain-status domain.name' if SSSD thinks it is online or
not at the time the cached (old) password is still used for
authentication.

Btw, I assume you have not set cached_auth_timeout in sssd.conf, using
this option might explain the observed behavior as well.

HTH

bye,
Sumit

> 
> Thank you,
> 
> - Xinhuan

> ___
> 389-users mailing list -- 389-us...@lists.fedoraproject.org
> To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/389-us...@lists.fedoraproject.org

> ___
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: Can not find slapi-plugin.h file in FreeIPA 4.6.4 install

[Elena Fedorov via FreeIPA-users]

This is the output of yum provides "*/slapi-plugin.h"
==
Repo: rhel-7-server-optional-rpms
Matched from:
Filename: /usr/include/dirsrv/slapi-plugin.h



389-ds-base-devel-1.3.1.6-26.el7_0.x86_64 : Development libraries for 389
  : Directory Server
Repo: rhel-7-server-optional-rpms
Matched from:
Filename: /usr/include/dirsrv/slapi-plugin.h



389-ds-base-devel-1.3.3.1-13.el7.x86_64 : Development libraries for 389
: Directory Server
Repo: rhel-7-server-optional-rpms
Matched from:
Filename: /usr/include/dirsrv/slapi-plugin.h



389-ds-base-devel-1.3.3.1-15.el7_1.x86_64 : Development libraries for 389
  : Directory Server
Repo: rhel-7-server-optional-rpms
Matched from:
Filename: /usr/include/dirsrv/slapi-plugin.h



389-ds-base-devel-1.3.3.1-16.el7_1.x86_64 : Development libraries for 389
  : Directory Server
Repo: rhel-7-server-optional-rpms
Matched from:
Filename: /usr/include/dirsrv/slapi-plugin.h



389-ds-base-devel-1.3.3.1-20.el7_1.x86_64 : Development libraries for 389
  : Directory Server
Repo: rhel-7-server-optional-rpms
Matched from:
Filename: /usr/include/dirsrv/slapi-plugin.h



389-ds-base-devel-1.3.3.1-23.el7_1.x86_64 : Development libraries for 389
  : Directory Server
Repo: rhel-7-server-optional-rpms
Matched from:
Filename: /usr/include/dirsrv/slapi-plugin.h



389-ds-base-devel-1.3.4.0-19.el7.x86_64 : Development libraries for 389
: Directory Server
Repo: rhel-7-server-optional-rpms
Matched from:
Filename: /usr/include/dirsrv/slapi-plugin.h



389-ds-base-devel-1.3.4.0-21.el7_2.x86_64 : Development libraries for 389
  : Directory Server
Repo: rhel-7-server-optional-rpms
Matched from:
Filename: /usr/include/dirsrv/slapi-plugin.h



389-ds-base-devel-1.3.4.0-26.el7_2.x86_64 : Development libraries for 389
  : Directory Server
Repo: rhel-7-server-optional-rpms
Matched from:
Filename: /usr/include/dirsrv/slapi-plugin.h



389-ds-base-devel-1.3.4.0-29.el7_2.x86_64 : Development libraries for 389
  : Directory Server
Repo: rhel-7-server-optional-rpms
Matched from:
Filename: /usr/include/dirsrv/slapi-plugin.h



389-ds-base-devel-1.3.4.0-30.el7_2.x86_64 : Development libraries for 389
  : Directory Server
Repo: rhel-7-server-optional-rpms
Matched from:
Filename: /usr/include/dirsrv/slapi-plugin.h



389-ds-base-devel-1.3.4.0-32.el7_2.x86_64 : Development libraries for 389
  : Directory Server
Repo: rhel-7-server-optional-rpms
Matched from:
Filename: /usr/include/dirsrv/slapi-plugin.h



389-ds-base-devel-1.3.4.0-33.el7_2.x86_64 : Development libraries for 389
  : Directory Server
Repo: rhel-7-server-optional-rpms
Matched from:
Filename: /usr/include/dirsrv/slapi-plugin.h



389-ds-base-devel-1.3.5.10-11.el7.x86_64 : Development libraries for 389
 : Directory Server
Repo: rhel-7-server-optional-rpms
Matched from:
Filename: /usr/include/dirsrv/slapi-plugin.h



389-ds-base-devel-1.3.5.10-12.el7_3.x86_64 : Development libraries for 389
   : Directory Server
Repo: rhel-7-server-optional-rpms
Matched from:
Filename: /usr/include/dirsrv/slapi-plugin.h



389-ds-base-devel-1.3.5.10-15.el7_3.x86_64 : Development libraries for 389
   : Directory Server
Repo: rhel-7-server-optional-rpms
Matched from:
Filename: /usr/include/dirsrv/slapi-plugin.h



389-ds-base-devel-1.3.5.10-18.el7_3.x86_64 : Development libraries for 389
   : Directory Server
Repo: rhel-7-server-optional-rpms
Matched from:
Filename: /usr/include/dirsrv/slapi-plugin.h



389-ds-base-devel-1.3.5.10-20.el7_3.x86_64 : Development libraries for 389
   : Directory Server
Repo: rhel-7-server-optional-rpms
Matched from:
Filename: /usr/include/dirsrv/slapi-plugin.h



389-ds-base-devel-1.3.5.10-21.el7_3.x86_64 : Development libraries for 389
   : Directory Server
Repo: rhel-7-server-optional-rpms
Matched from:
Filename: /usr/include/dirsrv/slapi-plugin.h



389-ds-base-devel-1.3.6.1-16.el7.x86_64 : Development libraries for 389
: Directory Server
Repo: rhel-7-server-optional-rpms
Matched 

[Freeipa-users] Re: Can not find slapi-plugin.h file in FreeIPA 4.6.4 install

[François Cami via FreeIPA-users]

Hi,

On Thu, Feb 28, 2019 at 12:27 AM Elena Fedorov via FreeIPA-users
 wrote:
>
>
> Hello,
> It's puzzling but the file required to be included in any custom plugin, 
> slapi-plugin.h, is nowhere to be found in the FreeIPA 4.6.4 install, 
> API_VERSION: 2.229
>
> The documentation refers to this file being either in:
>
> /usr/lib64/dirsrv/plugins/slapi-plugin.h.
> or in
> /usr/include/dirsrv/slapi-plugin.h.
>
> But it's not in either of this location. It's not at all on the box - I 
> searched from the top.

What does:
# yum provides "*/slapi-plugin.h"
tell you?

Cheers
François

> Please advise where I can find this header file? What package do I need to 
> install on RedHat 7.6 to get this file?
>
> Thanks,
> Elena.
>
>
> ___
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Can not find slapi-plugin.h file in FreeIPA 4.6.4 install

[Elena Fedorov via FreeIPA-users]

Hello,
It's puzzling but the file required to be included in any custom plugin,
slapi-plugin.h, is nowhere to be found in the FreeIPA 4.6.4 install,
API_VERSION: 2.229

The documentation refers to this file being either in:

/usr/lib64/dirsrv/plugins/slapi-plugin.h.
or in
/usr/include/dirsrv/slapi-plugin.h.

But it's not in either of this location.  It's not at all on the box - I
searched from the top.

Please advise where I can find this header file?  What package do I need to
install on RedHat 7.6 to get this file?

Thanks,
Elena.

___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: [389-users] How to invalidate local cache after user changed their password

[Grant Janssen via FreeIPA-users]

you might want to take a look at the man page for sss_cache

We use this sss_cache occationally to flush such problems.

- grant
This e-mail and any attachments are intended only for use by the addressee(s) 
named herein and may contain confidential information. If you are not the 
intended recipient of this e-mail, you are hereby notified any dissemination, 
distribution or copying of this email and any attachments is strictly 
prohibited. If you receive this email in error, please immediately notify the 
sender by return email and permanently delete the original, any copy and any 
printout thereof. The integrity and security of e-mail cannot be guaranteed.
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] ipa service vault - cannot find

[Dmitry Perets via FreeIPA-users]

Hi,

Sorry, I am probably missing something very basic in the way how the vault 
should work for services...

So my task is simple: let's say I want to store a secret for a script. That is, 
the script must be able to retrieve it in an unattended way. 
The script is running on a Linux server server.mydomain.com, which is enrolled 
in FreeIPA domain. 
The script is running under user "svc-user" which I've created on the FreeIPA 
just for that (so, its principal is svc-u...@mydomain.com).
Additionally, I've also created a service "MYSVC" on the FreeIPA (so I now also 
have the principal MYSVC\server.mydomain@mydomain.com).
Finally, I did not set any password for the user "svc-user" and I've configured 
its shell to be /sbin/nologin. Not sure if it will make any difference.

And now, with all this ready, I am trying to store my secret as admin, so that 
my script can retrieve it. 

I create a vault (I tried also standard one, but here I am showing an example 
with asymmetrical one, because all examples I found use it):

   kinit admin 
   

   ipa vault-add svc-vault --service MYSVC\server.mydomain.com --type 
asymmetric --public-key-file svc.pub.pem  
   ipa vault-archive svc-vault --service MYSVC\server.mydomain.com --data 


OK, secret is stored. And here is my vault:

   # ipa vault-find --services
   ---
   1 vault matched
   ---
  Vault name: svc-vault
  Type: asymmetric
  Vault service: MYSVC\server.mydomain@mydomain.com 
   
   Number of entries returned 1
   

Finally, I generate a keytab for my script:

   ipa-getkeytab -p MYSVC\server.mydomain.com -k 
/var/kerberos/krb5/user/856500016/client.keytab

OK... now I clean up with "kdestroy" and try to run my script as a user 
"svc-user".
And the script is trying to do this:

   kinit MYSVC\server.mydomain.com -k -t 
/var/kerberos/krb5/user/856500016/client.keytab 
   klist
   ipa vault-find --services

... And the problem is that it simply doesn't find the svc-vault.
It does seem like it manages to get the Kerberos ticket, this is the output 
from klist (inside the script):

   Default principal: MYSVC\server.mydomain@mydomain.com

   Valid starting   Expires  Service principal
   02/27/2019 17:04:58  02/28/2019 17:04:58  krbtgt/mydomain@mydomain.com

Now... If I add the user "svc-user" as a member to my svc-vault, add the 
svc-user to the keytab and then use "kinit svc-user" in my script, then it 
seems to work.
But I don't understand then the whole point of "service vault"... what's the 
purpose of the MYSVC/server.mydomain.com principle here actually...?

And another question - can't exactly the same (with "svc-user" in keytab) work 
also for a standard vault, without keys...? 
Because it looks like it becomes exactly the same usecase as if I just 
interactively use the vault shared with svc-user...

Thanks!
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: Ca signed very for non-IPA client

[Bret Wortman via FreeIPA-users]

Answered my own question. When I removed the "-BEGIN CERTIFICATE 
REQUEST-" and corresponding end lines, then we got a new error which we can 
easily run to ground since it's just a hostname format mismatch (short vs FQDN).

Bret Wortman
Founder, Damascus Products, LLC

855-644-2783 (tel:855-644-2783) | b...@wrapbuddies.co 
(https://link.getmailspring.com/link/61c2b7e1-42c6-44c7-87b6-2a29f43b1...@getmailspring.com/0?redirect=mailto%3Abret%40wrapbuddies.co=ZnJlZWlwYS11c2Vyc0BsaXN0cy5mZWRvcmFob3N0ZWQub3Jn)

http://wrapbuddies.co/ 
(https://link.getmailspring.com/link/61c2b7e1-42c6-44c7-87b6-2a29f43b1...@getmailspring.com/1?redirect=http%3A%2F%2Fwrapbuddies.co%2F=ZnJlZWlwYS11c2Vyc0BsaXN0cy5mZWRvcmFob3N0ZWQub3Jn)

70 Main St. Suite 23 Warrenton, VA 20186

On Feb 27 2019, at 6:45 am, Bret Wortman  wrote:
> Well, groovy except that we still can't issue certs against non-IPA systems 
> due to the same "TypeError: Incorrect padding" message in 
> /var/log/httpd/error_log as before.
>
> I was able to issue a cert to a client system, so is this likely a problem 
> with how the CSR is being created on ESXi?
>
> Bret Wortman
> Founder, Damascus Products, LLC
>
> 855-644-2783 (tel:855-644-2783) | b...@wrapbuddies.co 
> (https://link.getmailspring.com/link/61c2b7e1-42c6-44c7-87b6-2a29f43b1...@getmailspring.com/6?redirect=mailto%3Abret%40wrapbuddies.co=ZnJlZWlwYS11c2Vyc0BsaXN0cy5mZWRvcmFob3N0ZWQub3Jn)
>
>
>
>
> http://wrapbuddies.co/ 
> (https://link.getmailspring.com/link/61c2b7e1-42c6-44c7-87b6-2a29f43b1...@getmailspring.com/7?redirect=http%3A%2F%2Fwrapbuddies.co%2F=ZnJlZWlwYS11c2Vyc0BsaXN0cy5mZWRvcmFob3N0ZWQub3Jn)
>
>
>
> 70 Main St. Suite 23 Warrenton, VA 20186
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Feb 27 2019, at 6:31 am, Bret Wortman via FreeIPA-users 
>  wrote:
> > Rob,
> >
> > I can run "ipa help" on 2 of the 3; the 3rd yields this:
> > # ipa help
> > ipa: ERROR: No valid Negotiate header in server response
> >
> > Through some additional digging & log mining this morning, I figured out 
> > that something went tango uniform in our NTP configuration, so two of the 
> > servers were agreeing on the time (though incorrectly!) and this one, while 
> > closer, was far enough off the others to cause a problem. I synced all 3 
> > manually to a time source and voila. Everything's back and looking groovy.
> >
> > Bret Wortman
> > Founder, Damascus Products, LLC
> >
> > 855-644-2783 (tel:855-644-2783) | b...@wrapbuddies.co 
> > (https://link.getmailspring.com/link/61c2b7e1-42c6-44c7-87b6-2a29f43b1...@getmailspring.com/12?redirect=https%3A%2F%2Flink.getmailspring.com%2Flink%2FADADC439-6997-4785-8C55-D02AF4A61506%40getmailspring.com%2F0%3Fredirect%3Dmailto%253Abret%2540wrapbuddies.co%26recipient%3DZnJlZWlwYS11c2Vyc0BsaXN0cy5mZWRvcmFob3N0ZWQub3Jn=ZnJlZWlwYS11c2Vyc0BsaXN0cy5mZWRvcmFob3N0ZWQub3Jn)
> >
> >
> >
> >
> > http://wrapbuddies.co/ 
> > (https://link.getmailspring.com/link/61c2b7e1-42c6-44c7-87b6-2a29f43b1...@getmailspring.com/13?redirect=https%3A%2F%2Flink.getmailspring.com%2Flink%2FADADC439-6997-4785-8C55-D02AF4A61506%40getmailspring.com%2F1%3Fredirect%3Dhttp%253A%252F%252Fwrapbuddies.co%252F%26recipient%3DZnJlZWlwYS11c2Vyc0BsaXN0cy5mZWRvcmFob3N0ZWQub3Jn=ZnJlZWlwYS11c2Vyc0BsaXN0cy5mZWRvcmFob3N0ZWQub3Jn)
> >
> >
> >
> > 70 Main St. Suite 23 Warrenton, VA 20186
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > On Feb 26 2019, at 3:33 pm, Rob Crittenden  wrote:
> > > Bret Wortman wrote:
> > > > I don't think it's the CSR. We've got 3 IPA servers. Two seem to be
> > > > working just fine. One refuses to start named and /var/log/messages says
> > > > it's due to:
> > > >
> > > > bind-dyndb-ldap version 11.1 compiled at 13:38:22 Aug 23, 2017, compiler
> > > > 4.8.5 20150623 (Red Hat 4.8.5-16)
> > > > LDAP error: Invalid credentials: bind to LDAP server failed
> > > > couldn't establish connection in LDAP connection pool: permission denied
> > > > dynamic database 'ipa' configuration failed: permission denied
> > > >
> > > > I don't believe anyone changed our authentication, and in fact the other
> > > > two hosts don't have these issues. Where should I be looking first? This
> > > > one is our primary CA, so I'd rather not lose it...
> > >
> > >
> > > I'm not sure what you mean. Are you saying you can submit a request like
> > > this on 2 of the 3 servers, or something else?
> > >
> > > AFAIR bind-dyndb-ldap has its own keytab, /etc/named.keytab. I guess I'd
> > > ensure that it is: readable, has matching kvno, can read/write the socket.
> > >
> > > rob
> > > >
> > > >
> > > > photo
> > > > *Bret Wortman*
> > > > Founder, Damascus Products, LLC
> > > >
> > > > 855-644-2783  | b...@wrapbuddies.co
> > > > 
> > > >
> > > > 

[Freeipa-users] Re: Ca signed very for non-IPA client

[Bret Wortman via FreeIPA-users]

Well, groovy except that we still can't issue certs against non-IPA systems due 
to the same "TypeError: Incorrect padding" message in /var/log/httpd/error_log 
as before.

I was able to issue a cert to a client system, so is this likely a problem with 
how the CSR is being created on ESXi?

Bret Wortman
Founder, Damascus Products, LLC

855-644-2783 (tel:855-644-2783) | b...@wrapbuddies.co 
(https://link.getmailspring.com/link/85eccf63-a370-4ebd-92a7-6e031d33c...@getmailspring.com/0?redirect=mailto%3Abret%40wrapbuddies.co=ZnJlZWlwYS11c2Vyc0BsaXN0cy5mZWRvcmFob3N0ZWQub3Jn)

http://wrapbuddies.co/ 
(https://link.getmailspring.com/link/85eccf63-a370-4ebd-92a7-6e031d33c...@getmailspring.com/1?redirect=http%3A%2F%2Fwrapbuddies.co%2F=ZnJlZWlwYS11c2Vyc0BsaXN0cy5mZWRvcmFob3N0ZWQub3Jn)

70 Main St. Suite 23 Warrenton, VA 20186

On Feb 27 2019, at 6:31 am, Bret Wortman via FreeIPA-users 
 wrote:
> Rob,
>
> I can run "ipa help" on 2 of the 3; the 3rd yields this:
> # ipa help
> ipa: ERROR: No valid Negotiate header in server response
>
> Through some additional digging & log mining this morning, I figured out that 
> something went tango uniform in our NTP configuration, so two of the servers 
> were agreeing on the time (though incorrectly!) and this one, while closer, 
> was far enough off the others to cause a problem. I synced all 3 manually to 
> a time source and voila. Everything's back and looking groovy.
>
> Bret Wortman
> Founder, Damascus Products, LLC
>
> 855-644-2783 (tel:855-644-2783) | b...@wrapbuddies.co 
> (https://link.getmailspring.com/link/85eccf63-a370-4ebd-92a7-6e031d33c...@getmailspring.com/6?redirect=https%3A%2F%2Flink.getmailspring.com%2Flink%2FADADC439-6997-4785-8C55-D02AF4A61506%40getmailspring.com%2F0%3Fredirect%3Dmailto%253Abret%2540wrapbuddies.co%26recipient%3DZnJlZWlwYS11c2Vyc0BsaXN0cy5mZWRvcmFob3N0ZWQub3Jn=ZnJlZWlwYS11c2Vyc0BsaXN0cy5mZWRvcmFob3N0ZWQub3Jn)
>
>
>
>
> http://wrapbuddies.co/ 
> (https://link.getmailspring.com/link/85eccf63-a370-4ebd-92a7-6e031d33c...@getmailspring.com/7?redirect=https%3A%2F%2Flink.getmailspring.com%2Flink%2FADADC439-6997-4785-8C55-D02AF4A61506%40getmailspring.com%2F1%3Fredirect%3Dhttp%253A%252F%252Fwrapbuddies.co%252F%26recipient%3DZnJlZWlwYS11c2Vyc0BsaXN0cy5mZWRvcmFob3N0ZWQub3Jn=ZnJlZWlwYS11c2Vyc0BsaXN0cy5mZWRvcmFob3N0ZWQub3Jn)
>
>
>
> 70 Main St. Suite 23 Warrenton, VA 20186
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Feb 26 2019, at 3:33 pm, Rob Crittenden  wrote:
> > Bret Wortman wrote:
> > > I don't think it's the CSR. We've got 3 IPA servers. Two seem to be
> > > working just fine. One refuses to start named and /var/log/messages says
> > > it's due to:
> > >
> > > bind-dyndb-ldap version 11.1 compiled at 13:38:22 Aug 23, 2017, compiler
> > > 4.8.5 20150623 (Red Hat 4.8.5-16)
> > > LDAP error: Invalid credentials: bind to LDAP server failed
> > > couldn't establish connection in LDAP connection pool: permission denied
> > > dynamic database 'ipa' configuration failed: permission denied
> > >
> > > I don't believe anyone changed our authentication, and in fact the other
> > > two hosts don't have these issues. Where should I be looking first? This
> > > one is our primary CA, so I'd rather not lose it...
> >
> >
> > I'm not sure what you mean. Are you saying you can submit a request like
> > this on 2 of the 3 servers, or something else?
> >
> > AFAIR bind-dyndb-ldap has its own keytab, /etc/named.keytab. I guess I'd
> > ensure that it is: readable, has matching kvno, can read/write the socket.
> >
> > rob
> > >
> > >
> > > photo
> > > *Bret Wortman*
> > > Founder, Damascus Products, LLC
> > >
> > > 855-644-2783  | b...@wrapbuddies.co
> > > 
> > >
> > > http://wrapbuddies.co/
> > > 
> > >
> > > 70 Main St. Suite 23 Warrenton, VA 20186
> > > 
> > > 
> > >  
> > > 
> > >  
> > > 
> > >
> > > On Feb 26 2019, at 10:22 am, Bret Wortman via FreeIPA-users
> > >  wrote:
> > >
> > > It /looks/ like 

[Freeipa-users] Re: Ca signed very for non-IPA client

[Bret Wortman via FreeIPA-users]

Rob,

I can run "ipa help" on 2 of the 3; the 3rd yields this:
# ipa help
ipa: ERROR: No valid Negotiate header in server response

Through some additional digging & log mining this morning, I figured out that 
something went tango uniform in our NTP configuration, so two of the servers 
were agreeing on the time (though incorrectly!) and this one, while closer, was 
far enough off the others to cause a problem. I synced all 3 manually to a time 
source and voila. Everything's back and looking groovy.

Bret Wortman
Founder, Damascus Products, LLC

855-644-2783 (tel:855-644-2783) | b...@wrapbuddies.co 
(https://link.getmailspring.com/link/adadc439-6997-4785-8c55-d02af4a61...@getmailspring.com/0?redirect=mailto%3Abret%40wrapbuddies.co=ZnJlZWlwYS11c2Vyc0BsaXN0cy5mZWRvcmFob3N0ZWQub3Jn)

http://wrapbuddies.co/ 
(https://link.getmailspring.com/link/adadc439-6997-4785-8c55-d02af4a61...@getmailspring.com/1?redirect=http%3A%2F%2Fwrapbuddies.co%2F=ZnJlZWlwYS11c2Vyc0BsaXN0cy5mZWRvcmFob3N0ZWQub3Jn)

70 Main St. Suite 23 Warrenton, VA 20186

On Feb 26 2019, at 3:33 pm, Rob Crittenden  wrote:
> Bret Wortman wrote:
> > I don't think it's the CSR. We've got 3 IPA servers. Two seem to be
> > working just fine. One refuses to start named and /var/log/messages says
> > it's due to:
> >
> > bind-dyndb-ldap version 11.1 compiled at 13:38:22 Aug 23, 2017, compiler
> > 4.8.5 20150623 (Red Hat 4.8.5-16)
> > LDAP error: Invalid credentials: bind to LDAP server failed
> > couldn't establish connection in LDAP connection pool: permission denied
> > dynamic database 'ipa' configuration failed: permission denied
> >
> > I don't believe anyone changed our authentication, and in fact the other
> > two hosts don't have these issues. Where should I be looking first? This
> > one is our primary CA, so I'd rather not lose it...
>
>
> I'm not sure what you mean. Are you saying you can submit a request like
> this on 2 of the 3 servers, or something else?
>
> AFAIR bind-dyndb-ldap has its own keytab, /etc/named.keytab. I guess I'd
> ensure that it is: readable, has matching kvno, can read/write the socket.
>
> rob
> >
> >
> > photo
> > *Bret Wortman*
> > Founder, Damascus Products, LLC
> >
> > 855-644-2783  | b...@wrapbuddies.co
> > 
> >
> > http://wrapbuddies.co/
> > 
> >
> > 70 Main St. Suite 23 Warrenton, VA 20186
> > 
> > 
> >  
> > 
> >  
> > 
> >
> > On Feb 26 2019, at 10:22 am, Bret Wortman via FreeIPA-users
> >  wrote:
> >
> > It /looks/ like we've done everything in your guide. I've sent the
> > requestor the docs at
> > https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/linux_domain_identity_authentication_and_policy_guide/certificates#requesting-cert-certutil
> > 
> > to see if that gets us any further in generating a CSR that works.
> >
> >
> > photo
> > *Bret Wortman*
> > Founder, Damascus Products, LLC
> >
> > 855-644-2783  | b...@wrapbuddies.co
> > 
> >
> > http://wrapbuddies.co/
> > 

[Freeipa-users] Re: OTP via LDAP auth time sync

[Callum Smith via FreeIPA-users]

Dear Rob, All,

Just to be clear, we have indeed tracked this down to another issue, and the 
OTP/LDAP timing is fine. I imagine you already knew this, but this is confirmed 
to _not_ be an issue.

Regards,
Callum

--

Callum Smith
Research Computing Core
Wellcome Trust Centre for Human Genetics
University of Oxford
e. cal...@well.ox.ac.uk

On 4 Feb 2019, at 22:06, Rob Crittenden 
mailto:rcrit...@redhat.com>> wrote:

Callum Smith via FreeIPA-users wrote:
Dear All,

I'm seeing issues with the time synchronisation for OTP but ONLY for
authentication through LDAP and not through kerberos. Is this even
possible or am I going down the wrong rabbit hole on this issue. The
error presents as LDAP authentication giving "ldap operation failed"
when authentication to HashiCorp Vault, configured to auth against IPA
over LDAP, if the token is slightly old.

Have you been able to define a range for "slightly old"? Is there some
latency that is causing issue?

Is anything logged in the 389-ds error log when the operations error
fires? I'm not sure which error level would help in this case, some can
be kinda spammy. Is this easily reproducible on an otherwise quiet system?

rob

___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org