Hello Tom,
Version and OS:
we have kerberos 1.9.2 version.
It is running under Linux (x86_64 GNU/Linux).
KDC Traffic :
we do have heavy kadmin traffic.
we used to get avg or 4-7 Authentication request per second
For updating kerbero
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
The MIT Kerberos Team announces the availability of MIT Kerberos 5
Release 1.10.3. Please see below for a list of some major changes
included, or consult the README file in the source tree for a more
detailed list of significant changes.
RETRIEVING K
Abhilash S writes:
> Hello,
>
> I need few information on the kadmin.local utility.
>
> In few occasions am getting error "Cannot lock database while modifying"
> when trying to modify or change the password of a principal.
> Is it due to lock on KDC principal db file, or in what situations this
Jeremy Hunt writes:
> Hi Mauricio,
>
> Doug is right, I misread your request, my apologies.
>
> Googling kerberos, nat and ssh gives many responses all saying that the
> only way to do this is to use tickets with no address in them. You can
> do this by using the kinit command with either the -
Hi Mauricio,
Doug is right, I misread your request, my apologies.
Googling kerberos, nat and ssh gives many responses all saying that the
only way to do this is to use tickets with no address in them. You can
do this by using the kinit command with either the -n, -a or -A switch.
For security
Hello,
I need few information on the kadmin.local utility.
In few occasions am getting error "Cannot lock database while modifying"
when trying to modify or change the password of a principal.
Is it due to lock on KDC principal db file, or in what situations this can
occur.
I am seeing this occu
On 08/08/2012 12:33 PM, Greg Hudson wrote:
> If the server is running krb5 1.7 or later, this kind of problem should
> result in a "Wrong principal in request" error in the sshd output (which
> is still not very clear, but at least helps distinguish the problem from
> sshd trying to acquire the wro
On 08/08/2012 12:03 PM, Matt Garman wrote:
> I don't know enough about how Kerberos works, but I'll speculate a
> guess as to what was wrong yesterday: after a failed gssapi-with-mic
> login attempt, some "residual stuff" gets attached to the original
> TGT, some kind of "cache" of the "permission
On Tue, Aug 7, 2012 at 11:40 PM, Greg Hudson wrote:
> On 08/07/2012 01:23 PM, Matt Garman wrote:
>> [root@lnxsvr11 ~]# grep 192.168.187.67 /etc/hosts
>> 192.168.187.67 lnxsvr11.mydomain.com lnxsvr11
>> [root@lnxsvr11 ~]# grep "lnxsvr11\." /etc/hosts
>> 192.168.187.67 l
On 8/7/2012 11:12 PM, Jeremy Hunt wrote:
>
> Reverse the order of aliases for the IP address in your /etc/hosts file.
> The first named alias is used for your ticket generation. This is a
> common problem with short and FQDNs in /etc/hosts.
Then ssh to ssh.lan.com would work, but not ssh to ker
10 matches
Mail list logo
