Can two slaves connect to the same master using the _same_ credentials
and have replication work properly?
Why do I want to do this? I would like to deploy identical KDC slaves
using Kubernetes "pods". Since the pods are identical, they would be
using the same credentials.
Of course, in
For some time we have been recommending people use the setting "rdns =
false" in the "[libdefaults]" section. However, recently we have run
across one case where that setting is causing an issue.
A client is running a Perl script where, using Net::LDAP, they make a
GSSAPI connection to our
in the SRV record.
Here is the question:
Has anyone on the list encountered a Kerberos client or library that
used DNS discovery that COULDN'T handle an SRV record with a CNAME?
Thanks, Adam Lewenberg
is around 23MB.
Anyone have any troubleshooting steps to find out why ipropd is so slow?
Thanks, Adam Lewenberg
Is it possible to copy a single Heimdal KDC entry from one database to
another?
For example, assume I have two Heimdal KDC's both using the same master
key, KDC A and KDC B. I create a principal in KDC A using the "-r"
option so that the password is randomly generated. Is it possible to
6-22T11:33:12
When I dump the master's log using 'iprop-log dump' it shows 7 entries.
I thought that ipropd-slave would get the entire database if there was
no database to start with. But this is not happening.
Any ideas?
Thank you, Adam Lewenberg
On 6/15/2018 6:21 PM, Viktor Dukhovni wrote:
On Jun 15, 2018, at 6:29 PM, Adam Lewenberg wrote:
This (or something much like it) appears in the initial replication on three
separate 1.5.2 slaves:
You *really* should upgrade the slaves as soon as possible,
however:
2018-06-15T17:45
me think that the database on the master is corrupted in some
subtle way.
I am hoping that someone can tell me some way to query or examine the
database on the master to get some information that might throw some
light on why this particular principal behaves this way.
Adam Lewenberg
On
On 6/15/2018 3:04 PM, Viktor Dukhovni wrote:
On Jun 15, 2018, at 5:31 PM, Adam Lewenberg wrote:
PROBLEM: Some of the principals will not replicate.
Well updates to the principal are not replicating...
If I go on the master and change the password of one of these problematic
K-INIT ACL:
Aliases:
--
One extra piece of information. The master's database came by hprop'ing
to it from a 1.5.2 master.
QUESTION: What could be a reason for this principal not to replicate?
Adam Lewenberg
We will have to do some testing and see what happens.
I looked at the man page and this is what it says:
--time-gone=time
time of inactivity after which a slave is considered gone
(default 5 min)
--time-lost=time
time before server is considered lost (default 5
replication even after such long network outage? Are there
configuration options for ipropd-master/ipropd-slave that need to be set
to take into account long outages?
Thank you, Adam Lewenberg
= stanford.edu
kadmind_port = 749
}
Since the KDC service's realm is stanford.edu, is the KDC even using
those settings? If so, how?
Adam Lewenberg
On 1/31/2018 10:57 PM, Harald Barth wrote:
Short of stopping the OpenAFS client, is there a way I can run kinit so
that it does not try to provision this AFS ticket?
kinit --no-afslog
That solved the problem nicely. Thanks!
Adam
AFAIK all the long options can be reversed with --no...
I notice that when I do a "kinit username", after the password is
accepted the kinit client attempts to get a kerberos ticket for the AFS
service. This is, I am assuming, because of the OpenAFS client running
on the server.
Short of stopping the OpenAFS client, is there a way I can run kinit
How large can the kvno get before something breaks?
I have automated testing set up that changes the password of a special
test principal periodically, so this principal's kvno will eventually
get quite large.
I trying to replicate the database from a master to a slave using hprop.
However, I am getting this error:
---
master# hprop -v kdc-slave-pre.example.com
connect(kdc-slave-pre.example.com): Connection refused
hprop: failed to contact
-authentication does not help mitigate against this sort of attack.In
other words, pre-authentication helps against attacks from "outsiders"
but not from existing users.
Is this correct?
Thanks, Adam Lewenberg
On 4/7/2017 12:55 PM, Jeffrey Hutzelman wrote:
On Fri, 2017-04-07 at 12:31 -0700, Adam Lewenberg wrote:
I am trying to set up iprop replication for a slave KDC running on a
container in an EC2 instance in Amazon Web Services (AWS). We are
running Heimdal 1.5.2.
When the slave ipropd-slave
On 4/1/2017 5:22 PM, Jeffrey Hutzelman wrote:
On Sat, 2017-04-01 at 16:59 -0700, Adam Lewenberg wrote:
I am looking for a quick way to get a snapshot of the Kerberos
database
file.
The most obvious way to do this would be to shutdown the kerberos
service, copy the file, and restart
On 4/1/2017 5:52 PM, Nico Williams wrote:
On Sat, Apr 01, 2017 at 04:59:56PM -0700, Adam Lewenberg wrote:
I am looking for a quick way to get a snapshot of the Kerberos database
file.
The most obvious way to do this would be to shutdown the kerberos service,
copy the file, and restart
ps.
If you use a master key and you back up all your files _except_ the
master key to some remote location, wouldn't that suffice to protect the
database in that remote location?
Adam Lewenberg
Even if we could put the master key in a hardware token, that would not
be sufficient to make th
configure our Kerberos and/or OpenLDAP so
that clients using Kerberos with reverse DNS as part of the
authentication process still works?
Thanks, Adam Lewenberg
23 matches
Mail list logo
