After upgrading to MIT Kerberos 1.8.1, I get KRB5KRB_AP_ERR_MODIFIED while
trying to authenticate to certain devices; so far, a NetApp filer, and
Windows hosts running BitVise WinSSHD and MS SQL Server (alll part of a
Windows AD realm). Clients are OpenSSH, Samba, and FreeTDS on Solaris.
The same
Hello,
Is there a way to propagate the Active Directory Kerberos principals
and their passwords to an MIT KDC?
I would think that it may not be that simple but have to ask.
Thank you
Kerberos mailing list Kerberos@mit.edu
https://mailman.
You could do this with a password change notification DLL on the AD domain
controllers. There are some DLLs around that already do this.
Of course, you can only propagate when a password is changed.
-Ross
-Original Message-
From: kerberos-boun...@mit.edu [mailto:kerberos-boun...@mit.edu
This setup used to work until I recently upgraded my Ubuntu
installation from 9.10 to 10.04.
I don't understand what has changed, or what could give the following
error. I am using the same /etc/krb5.conf.
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure. Minor
>
> Karmic 9.10: OpenSSH 5.1p1-6ubuntu2, libgssapi-krb5-2
> 1.7dfsg~beta3-1ubuntu0.6
> Lucid 10.04: OpenSSH 5.3p1-3ubuntu3, libgssapi-krb5-2 1.8.1+dfsg-2
This particular version change makes me suspect something related to DES
tickets. Does the service ticket you're trying to obtain have encryp
Ok, thank you for the information. I was hoping there was a way to do
something similar to a kprop from AD to an MIT KDC using some kind of
AD tool. But I also imagined that would not be the case since there
are likely many incompatibilities.
I think I need to read up on the Microsoft Kerberos docu
On Wed, 2 Jun 2010 10:04:25 -0700
Techie wrote:
> Ok, thank you for the information. I was hoping there was a way to do
> something similar to a kprop from AD to an MIT KDC using some kind of
> AD tool. But I also imagined that would not be the case since there
> are likely many incompatibilities
That is true.. I oversimplified a bit. This would allow you to have a KDC with
equivalent principals. You would need a trust relationship and the external
principal names set on the AD users as alternate security identities for the
synchronized principals to work for Windows logon, etc. I had si
On Wed, 2 Jun 2010 10:35:05 -0700
"Wilper, Ross A" wrote:
> That is true.. I oversimplified a bit. This would allow you to have a
> KDC with equivalent principals. You would need a trust relationship
> and the external principal names set on the AD users as alternate
> security identities for the
Simo Sorce writes:
> "Wilper, Ross A" wrote:
>> That is true.. I oversimplified a bit. This would allow you to have a
>> KDC with equivalent principals. You would need a trust relationship and
>> the external principal names set on the AD users as alternate security
>> identities for the synchro
On Wed, Jun 2, 2010 at 11:17 AM, Russ Allbery wrote:
> Simo Sorce writes:
>> "Wilper, Ross A" wrote:
>
>>> That is true.. I oversimplified a bit. This would allow you to have a
>>> KDC with equivalent principals. You would need a trust relationship and
>>> the external principal names set on the
On Wed, 02 Jun 2010 11:17:10 -0700
Russ Allbery wrote:
> Simo Sorce writes:
> > "Wilper, Ross A" wrote:
>
> >> That is true.. I oversimplified a bit. This would allow you to
> >> have a KDC with equivalent principals. You would need a trust
> >> relationship and the external principal names se
Simo Sorce writes:
> Russ Allbery wrote:
>> Given that we do this routinely at Stanford using cross-realm trust
>> exactly as Ross describes, I think you've misunderstood something. I
>> believe AD adds the PAC for you when you do what Ross says and
>> configure the external principal names as
Russ Allbery wrote:
> Simo Sorce writes:
>> Ah sorry, I thought he wanted to use them as completely alternative
>> users. If you do map each MIT principal to an existing Windows user then
>> it does work, although it seem to make sense only as a transition tool
>> to me.
>
> It's the way that we
"Christopher D. Clausen" writes:
> I advocate just using the Active Directory realm. It is much, much
> simpler to troubleshoot when there is no cross-realm invovled,
> especially when different groups operate the different realms.
> Other than some solvable issues of generating keytabs on non-
The link to ViewCVS on this page is broken:
http://web.mit.edu/kerberos/dist/testing.html#svn
And at least several "History" links in the OpenGrok viewer are also
broken, e.g. here:
http://src.mit.edu/krb5/xref/branches/krb5-1-8/src/lib/crypto/krb/arcfour/arcfour.c
--
Richard Silverman
r.
On Wed, 2010-06-02 at 03:33 -0400, Richard E. Silverman wrote:
> After upgrading to MIT Kerberos 1.8.1, I get KRB5KRB_AP_ERR_MODIFIED while
> trying to authenticate to certain devices; so far, a NetApp filer, and
> Windows hosts running BitVise WinSSHD and MS SQL Server (alll part of a
> Windows AD
"Richard E. Silverman" writes:
> The link to ViewCVS on this page is broken:
>
> http://web.mit.edu/kerberos/dist/testing.html#svn
Thanks. It should point to the right place now.
> And at least several "History" links in the OpenGrok viewer are also
> broken, e.g. here:
>
> http://src.mit.edu/
I find that OpenSSH (5.1p1 on both sides) will silently refuse to
delegate credentials if the principal being delegated lacks the
REQUIRES_PRE_AUTH attribute. Adding that attribute at the KDC and
re-issuing the principal's tickets causes everything to work perfectly.
Is this behavior intentional
Adam Megacz writes:
> I find that OpenSSH (5.1p1 on both sides) will silently refuse to
> delegate credentials if the principal being delegated lacks the
> REQUIRES_PRE_AUTH attribute. Adding that attribute at the KDC and
> re-issuing the principal's tickets causes everything to work perfectly.
On Wed, 2 Jun 2010, Greg Hudson wrote:
> On Wed, 2010-06-02 at 03:33 -0400, Richard E. Silverman wrote:
>> After upgrading to MIT Kerberos 1.8.1, I get KRB5KRB_AP_ERR_MODIFIED while
>> trying to authenticate to certain devices; so far, a NetApp filer, and
>> Windows hosts running BitVise WinSSHD a
21 matches
Mail list logo
