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
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
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
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
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 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
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
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 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
>
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
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
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
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
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
14 matches
Mail list logo