On 08/17/2016 08:54 PM, John Desantis wrote:
Hello all,
We've been re-using old host names and IP addresses for a new
deployment of nodes, and recently I've been seeing the messages pasted
below in the slapd-DC.DC.DC "error" log on our nodes.
[17/Aug/2016:10:30:30 -0400] - replica_generate_nex
On 17.8.2016 19:58, Guido Schmitz wrote:
> After some debugging, I found the error:
>
> cut =
> ipa : DEBUGstderr=
> ipa.ipapython.dnssec.bindmgr.BINDMgr: INFO attrs: {'idnsseckeyref':
> ['pkcs11:object=a1'], 'dn':
> 'cn=KSK-2014073634Z-a1,cn=keys,idnsname=myzo
Hi,
thank you. We are experiencing problems with LDAP access from IPA servers in
IPA-AD scenario with one-way trust (Win 2012).
So for ldap access IPA uses the xyz$@domain special trust account. According my
lab - this account is on the AD side considered as a member of Authenticated
users gr
Ludwig,
Thank you for your response!
> This is a normal scenario, but you could check if the simultaneous updates
> on 4 and 16 are intentional.
In regards to the simultaneous updates, the only items I have noted so far are:
* The time sync between the master (4) and replica (16) was off by
ab
realstarhealer wrote:
Hi,
I am in charge for a freeipa 4.1.0.18.el7 server with ldap backend and
noticed some expired certificates recently. Most of them but 2 are
auto-renewing by certmonger as I checked. All of them are self signed.
"CN=ipa-ca-agent" and "CN=Object Signing Cert" are not subsc
On 08/18/2016 12:48 AM, Devin Acosta wrote:
>
> My first primary FreeIPA Master server has gone belly up. When I try to start
> the server it shows this message in the "error' log. However the other issue
> i
> have is when I try to start the server using "ipactl start" it times out
> after
>
On Thu, 18 Aug 2016, Jan Karásek wrote:
Hi,
thank you. We are experiencing problems with LDAP access from IPA
servers in IPA-AD scenario with one-way trust (Win 2012).
So for ldap access IPA uses the xyz$@domain special trust account.
According my lab - this account is on the AD side considered
On 08/18/2016 03:15 PM, John Desantis wrote:
Ludwig,
Thank you for your response!
This is a normal scenario, but you could check if the simultaneous updates
on 4 and 16 are intentional.
In regards to the simultaneous updates, the only items I have noted so far are:
* The time sync between
Hi All,
While trying to automate IPA client registration programatically, i seems have
made my admin password out of sync between KDC and
/etc/krb5.keytab. Now when i try login into ipa GUI via admin i am getting "The
password or username is incorrect" - though i am trying with the corre
Great ! Thank you very much. It works !
Regards,
Jan
From: "Alexander Bokovoy"
To: "Jan Karásek"
Cc: freeipa-users@redhat.com
Sent: Thursday, August 18, 2016 4:03:14 PM
Subject: Re: [Freeipa-users] IPA-AD ldap acces - account ?
On Thu, 18 Aug 2016, Jan Karásek wrote:
>Hi,
>thank you
Hi
I am migrating to freeipa from openldap and have around 4000 clients
I had openned a another thread on that, but chose to start a new one here
as its a separate issue
I was able to change the nssslapd-maxdescriptors adding an ldif file
cat nsslapd-modify.ldif
dn: cn=config
changetype: modify
Ludwig,
> unfortunately this is not enough to determine what is going on. The
> intersting generated/used csn is only logged in the
> corresponding RESULT message and these are only the replication connections,
> it would be necessary to see the
> original ADD operation, was it added once or twice
Thanks Petr.
It seems like the only way to do it right now is to dump the keytab and
copy it to slave KDCs, as I couldn't find a way to have MIT Kerberos to use
the master key stored in the LDAP directly.
MIT Kerberos doesn't really support a master key stored elsewhere other
than using "key_stas
On 18.8.2016 23:36, Diogenes S. Jesus wrote:
> Thanks Petr.
>
> It seems like the only way to do it right now is to dump the keytab and
> copy it to slave KDCs, as I couldn't find a way to have MIT Kerberos to use
> the master key stored in the LDAP directly.
That is expected. If you want, just d
14 matches
Mail list logo