Re: appl/simple/client/sim_client.c uses internal APIs

[Benjamin Kaduk]

On Fri, Feb 24, 2023 at 04:27:28PM -0800, Russ Allbery wrote:
> 
> (There is the other problem that all of the effort, hardware support, and
> optimization work is going into TLS now, and it feels like a huge waste of
> energy to try to compete with TLS in the secure transport business.  But
> that's a whole different can of worms since TLS is very wedded to X.509
> certificates and there are a bunch of very good reasons to not want to use
> X.509 certificates for client authentication in a lot of situations.)

In case you haven't been following, OpenSSL is set to grow TLS raw public
key support soon, probably in 3.1 or so:
https://github.com/openssl/openssl/pull/18185
I've seen a number of places picking up on TLS with raw public key as an
option for secure transport when they don't want to be wedded to X.509
certificates (whether for client or for server).  You do have to supply
your own authorization layer, then, of course, but you may already have
one.

-Ben

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: appl/simple/client/sim_client.c uses internal APIs

[Benjamin Kaduk]

On Fri, Feb 24, 2023 at 02:50:35PM -0600, Nico Williams wrote:
> On Fri, Feb 24, 2023 at 12:19:53PM -0800, Russ Allbery wrote:
> > Nico Williams  writes:
> > > If you're just trying to set up a GSS context between a client and a
> > > server, then GSS is really simple, and much simpler than the krb5 API.
> > 
> > I'm very dubious about this statement.  The requirement to handle
> > negotiation and potential multiple round trips and all the complexity with
> > major and minor status codes makes the equivalent GSS code complicated and
> > annoying.
> 
[...]
> 
> RFC 7546 exists.

And https://github.com/kaduk/gssdoc/blob/master/gss-sample.c has the
un-processed version of the sample code from the RFC; I did compile and run
it during development of the RFC.

-Ben

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: how to delete wrong username from suggestions

[Benjamin Kaduk]

On Wed, Sep 29, 2021 at 02:02:57PM +, Jenei Péter wrote:
> Dear Sir/Madam,
> 
> I would like to know how to delete wrong data from the suggestions of the 
> Username field on the new credentials window.
> [cid:image001.png@01D7B54B.779CD320][cid:image002.png@01D7B54B.779CD320]
> I have already tried highliting the wrongly typed username and push 
> Delte/Shift+Delete/Ctrl+Delete/Alt+Delete/Crl+Alt+Delete (windows restarted) 
> but it did not do the trick.
> Thank you in advance

I think (but did not confirm) that these history entries are stored in the
windows registry.  Accordingly, the registry editor would be able to remove
them, but the usual disclaimers about the registry editor being a very
powerful tool that has the ability to inadvertently render your system
unusable apply.

-Ben

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: heimdal http proxy

[Benjamin Kaduk]

On Sun, Sep 12, 2021 at 07:49:57AM -0400, Jeffrey Altman wrote:
> On 9/11/2021 11:22 AM, Charles Hedrick (hedr...@rutgers.edu) wrote:
> > We don’t currently explore our Kerberos servers to the Internet, but we do 
> > have an https proxy for MIT kerberos. Heimal apparently has its own HTTP 
> > proxy. Does anyone know of software to implement the proxy?
> I believe the question that should be asked is
> 
>   "Can an https proxy client compatible with MIT Kerberos be implemented
> for Heidmal?"

My understanding is that MIT Kerberos just implemented compatibility for
Microsoft's MS-KKDCP protocol,
https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-kkdcp/5bcebb8d-b747-4ee5-9453-428aec1c5c38

-Ben

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Kerberos ksu not working with NFSv4 mount sec=krb5

[Benjamin Kaduk]

On Sat, May 22, 2021 at 02:22:08PM -0400, Jason Keltz wrote:
> Hi.
> 
> I'm unable to get ksu working wth krb5 NFSv4, and can't quite figure out 
> why.
> 
> I am logged into a RHEL7 system as a user "jas" (uid 1004) with working 
> Kerberos (Samba AD implementation).
> 
> I want to switch from user jas to user tdb (uid 1011) using ksu.
> 
> I set up a .k5login file in tdb account containing j...@ad.eecs.yorku.ca
> 
> If tdb home directory is mounted with sec=sys, as jas I can "ksu tdb" 
> and it works every time.
> 
> If tdb home directory is mounted with sec=krb5, ksu wants me to enter  a 
> password.
> 
> (Note that as jas I can still cat ~tdb/.k5login).
> 
> KRB5CCNAME is FILE:/tmp/krb5cc_1004
> 
> rpc.gssd -vvv returns:
> 
>  > handle_gssd_upcall: 'mech=krb5 uid=1011 enctypes=18,17,16,23,3,1,2 ' 
> (nfs/clnt0)
>  > krb5_not_machine_creds: uid 1011 tgtname (null)
>  > ERROR: GSS-API: error in gss_acquire_cred(): GSS_S_FAILURE 
> (Unspecified GSS failure.  Minor code may provide more information) - No 
> Kerberos credentials available: Credentials cache permissions incorrect 
> (filename: /tmp/krb5cc_1004)

This seems to say that setuid() succeeded, and now rpc.gssd is looking
around in /tmp/ for a credentials cache that has tickets that can
authenticate to NFS for the current user.  It seems that it's looking at
the krb5cc file from jas, that is owned by jas, and seeing that the
permissions don't match the (now-)expected tdb user as owner.


>  > looking for client creds with uid 1011 for server sea.eecs.yorku.ca 
> in /tmp
>  > CC '/tmp/krb5cc_1004' being considered, with preferred realm 
> 'AD.EECS.YORKU.CA'
>  > CC '/tmp/krb5cc_1004' owned by 1004, not 1011
>  > CC '/tmp/krb5ccmachine_AD.EECS.YORKU.CA' being considered, with 
> preferred realm 'AD.EECS.YORKU.CA'
>  > CC '/tmp/krb5ccmachine_AD.EECS.YORKU.CA' owned by 0, not 1011
>  > CC '/tmp/krb5cc_0' being considered, with preferred realm 
> 'AD.EECS.YORKU.CA'
>  > CC '/tmp/krb5cc_0' owned by 0, not 1011
>  > looking for client creds with uid 1011 for server sea.eecs.yorku.ca 
> in /run/user/%U
>  > Error doing scandir on directory '/run/user/1011': No such file or 
> directory
>  > doing error downcall
>  >
>  > handle_gssd_upcall: 'mech=krb5 uid=1011 enctypes=18,17,16,23,3,1,2 ' 
> (nfs/clnt0)
>  > krb5_not_machine_creds: uid 1011 tgtname (null)
>  > ERROR: GSS-API: error in gss_acquire_cred(): GSS_S_FAILURE 
> (Unspecified GSS failure.  Minor code may provide more information) - No 
> Kerberos credentials available: Credentials cache permissions incorrect 
> (filename: /tmp/krb5cc_1004)
>  > looking for client creds with uid 1011 for server sea.eecs.yorku.ca 
> in /tmp
>  > CC '/tmp/krb5cc_1004' being considered, with preferred realm 
> 'AD.EECS.YORKU.CA'
>  > CC '/tmp/krb5cc_1004' owned by 1004, not 1011
>  > CC '/tmp/krb5ccmachine_AD.EECS.YORKU.CA' being considered, with 
> preferred realm 'AD.EECS.YORKU.CA'
>  > CC '/tmp/krb5ccmachine_AD.EECS.YORKU.CA' owned by 0, not 1011
>  > CC '/tmp/krb5cc_0' being considered, with preferred realm 
> 'AD.EECS.YORKU.CA'
>  > CC '/tmp/krb5cc_0' owned by 0, not 1011
>  > looking for client creds with uid 1011 for server sea.eecs.yorku.ca 
> in /run/user/%U
>  > Error doing scandir on directory '/run/user/1011': No such file or 
> directory
>  > doing error downcall
> 
> If I actually enter the password then /tmp/krb5cc_1011 shows up, and 
> everything works.
> 
>  > handle_gssd_upcall: 'mech=krb5 uid=1011 enctypes=18,17,16,23,3,1,2 ' 
> (nfs/clnt0)
>  > krb5_not_machine_creds: uid 1011 tgtname (null)
>  > ERROR: GSS-API: error in gss_acquire_cred(): GSS_S_FAILURE 
> (Unspecified GSS failure.  Minor code may provide more information) - No 
> Kerberos credentials available: Credentials cache permissions incorrect 
> (filename: /tmp/krb5cc_1004)
>  > looking for client creds with uid 1011 for server sea.eecs.yorku.ca 
> in /tmp
>  > CC '/tmp/krb5cc_1004' being considered, with preferred realm 
> 'AD.EECS.YORKU.CA'
>  > CC '/tmp/krb5cc_1004' owned by 1004, not 1011
>  > CC '/tmp/krb5cc_1011.9bpz551G' being considered, with preferred realm 
> 'AD.EECS.YORKU.CA'
>  > CC 'FILE:/tmp/krb5cc_1011.9bpz551G'(t...@ad.eecs.yorku.ca) passed all 
> checks and has mtime of 1621645808
>  > CC '/tmp/krb5ccmachine_AD.EECS.YORKU.CA' being considered, with 
> preferred realm 'AD.EECS.YORKU.CA'
>  > CC '/tmp/krb5ccmachine_AD.EECS.YORKU.CA' owned by 0, not 1011
>  > CC '/tmp/krb5cc_0' being considered, with preferred realm 
> 'AD.EECS.YORKU.CA'
>  > CC '/tmp/krb5cc_0' owned by 0, not 1011
>  > using FILE:/tmp/krb5cc_1011.9bpz551G as credentials cache for client 
> with uid 1011 for server sea.eecs.yorku.ca
>  > using gss_krb5_ccache_name to select krb5 ccache 
> FILE:/tmp/krb5cc_1011.9bpz551G
>  > creating tcp client for server sea.eecs.yorku.ca
>  > DEBUG: port already set to 2049
>  > creating context with server n...@sea.eecs.yorku.ca
>  > DEBUG: serialize_krb5_ctx: lucid version!
>  > prepare_krb5_rfc4121_buffer: protocol 1
>  

Re: Kerberos KRB_AP_REQ message - Server name verification required ?

[Benjamin Kaduk]

On Fri, Mar 19, 2021 at 11:47:49PM +0530, Vipul Mehta wrote:
> Hi,
> 
> Suppose there are two servers A and B running under different kerberos
> service principals.
> If both the service principals have same password and kvno then kerberos
> long term encryption key will be same for both. Seems to be the case for
> windows KDC.
> 
> In such case, a client having service ticket for A tries to authenticate
> with that ticket with server B, should it work ? It is working fine in JDK
> implementation.
> 
> https://tools.ietf.org/html/rfc1510#page-21 : in RFC it is not clear
> whether server should validate server principal in the service ticket when
> KRB_AP_REQ message is received. Looks like just decryption with key is
> sufficient along with some other validations but i don't find server name
> validation explicitly mentioned.

I note that RFC 1510 has been obsoleted by RFC 4120 (but
https://tools.ietf.org/html/rfc4120#section-3.2.3 contains essentially the
same text that you reference).

My understanding is that the RFC authors assumed that different services
would have different keys, so the scenario you describe would not occur
(though, as you know, the situation does occur quite often in Active
Directory environments).  Since the Ticket sname is in the unencrypted part
of the ticket, there is no value in validating its contents, as the Ticket
could be re-encoded with an arbitrary sname value.  It is, in essence, just
a hint for locating the proper key, in the same that the realm is (and the
realm is explicitly discussed as serving this role in the referenced text).

-Ben

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: kerberos and web authentication

[Benjamin Kaduk]

On Fri, Aug 21, 2020 at 08:04:24PM -0400, Rita wrote:
> hi
> 
> The webserver has DNS aliases but not multiple IPs. On a client level is it

(temporarily) forcing the name to resolve to just a single IP, e.g., via
/etc/hosts, would be one possible diagnostic measure.

> possible to disable the reverse lookup? I am not sure if its backed up a

See the 'rdns' keyword at
http://web.mit.edu/kerberos/krb5-latest/doc/admin/conf_files/krb5_conf.html#libdefaults

> pool of servers -- is there a way to find out from a client?

In general, no; one can make inferences from careful inspection of response
headers, request/response timing for exchanges that require server-side
state, and the like, but it may require some expertise to interpret the
results.

-Ben

> On Fri, Aug 21, 2020 at 7:30 PM Benjamin Kaduk  wrote:
> 
> > On Thu, Aug 13, 2020 at 07:10:42AM -0400, Rita wrote:
> > > I created a user keytab. I use curl to authenticate against a web server.
> > > `curl -u : --negotitate` it works randomly (about 33% accuracy). I am
> > > trying to figure out if its a webserver issue or kerberos issue. Is there
> > > anything else I can do?
> >
> > There's (at least) a couple things that can come into play for this sort of
> > scenario (not least because HTTP Negotiate violates some fundamental
> > assumptions about message- vs. connection-oriented):
> >
> > Does the web server's hostname have multiple IP addresses in the DNS?  (Is
> > reverse DNS used for principal canonicalization by the krb5 library?  The
> > default is "yes" in many versions.)
> >
> > Does the web server have a pool of backend servers behind a load balancer?
> >
> > -Ben
> >
> 
> 
> -- 
> --- Get your facts first, then you can distort them as you please.--

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: kerberos and web authentication

[Benjamin Kaduk]

On Thu, Aug 13, 2020 at 07:10:42AM -0400, Rita wrote:
> I created a user keytab. I use curl to authenticate against a web server.
> `curl -u : --negotitate` it works randomly (about 33% accuracy). I am
> trying to figure out if its a webserver issue or kerberos issue. Is there
> anything else I can do?

There's (at least) a couple things that can come into play for this sort of
scenario (not least because HTTP Negotiate violates some fundamental
assumptions about message- vs. connection-oriented):

Does the web server's hostname have multiple IP addresses in the DNS?  (Is
reverse DNS used for principal canonicalization by the krb5 library?  The
default is "yes" in many versions.)

Does the web server have a pool of backend servers behind a load balancer?

-Ben

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: A possible small bug in SPNEGO handling when dealing with NETAPP servers

[Benjamin Kaduk]

On Mon, Jun 29, 2020 at 03:22:22PM -0700, Richard Sharpe wrote:
> Hi folks,
> 
> I have recently had to deal with a problem when calling
> gss_init_sec_context after receiving an SPNEGO negTokenTarg from
> NetApp C-Mode and 7-Mode servers.
> 
> After some investigation, I tracked it down to
> src/lib/gssapi/spnego/spnego_mech.c in get_mech_oid when handling the
> supportedMech OID.
> 
> The code was directly extracting the length from the buffer but (as
> you can see from the capture attached in the Session Setup Response)
> NetApp encodes the length of the OID in a longer form as 0x82 0x00
> 0x09 instead of the short-form 0x09.
> 
> To fix this I simply changed the code to call gssint_get_der_length to
> retrieve the OID length. The following patch shows the change:
> 
> --
> --- a/src/lib/gssapi/spnego/spnego_mech.c.orig  2017-03-02
> 22:06:02.0 +
> +++ b/src/lib/gssapi/spnego/spnego_mech.c   2020-06-29
> 21:07:05.749062072 +
> @@ -3256,6 +3256,7 @@
> gss_OID_desctoid;
> gss_OID mech_out = NULL;
> unsigned char   *start, *end;
> +   unsigned intbytes;
> 
> if (length < 1 || **buff_in != MECH_OID)
> return (NULL);
> @@ -3264,9 +3265,11 @@
> end = start + length;
> 
> (*buff_in)++;
> -   toid.length = *(*buff_in)++;
> 
> -   if ((*buff_in + toid.length) > end)
> +   /* Get the length in a way that allows more impls to work */
> +   toid.length = gssint_get_der_length(buff_in, length - 1, );
> +
> +   if (toid.length < 0 || (*buff_in + toid.length) > end)
> return (NULL);
> 
> toid.elements = *buff_in;
> ---
> 
> With this change my test program (based on libsmb2) now works against
> both Windows 2012 and NetApp C-Mode servers.
> 
> Should I file a bug about this?

Probably, for visibility if nothing else.

Do you know if the length is getting encoded in non-DER BER (i.e., with a
longer encoding) or if the actual length is large enough that it cannot fit
in a single byte?

Thanks,

Ben

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: What form is the timestamp in the KRB5_TRACE log (and why)

[Benjamin Kaduk]

Whoops, I copied the wrong name; the public interface has docs at
http://web.mit.edu/kerberos/krb5-1.18/doc/appdev/refs/api/krb5_us_timeofday.html
and peeking at the source it's a gettimeofday()-like on unix-like systems.
So the unix epocy conversion ought to be working, in my reading, yes.

-Ben

On Fri, Apr 03, 2020 at 08:21:39AM -0600, Todd Grayson wrote:
> Ok but does that mean Unix Epoch time conversion should be working, or is
> there some other form of secret decoder ring that is used to translate to
> system time?  In troubleshooting/debugging scenarios, being able to
> associate the timestamps from the KRB5_TRACE that has been running over an
> extended period with external services integrating with kerberos would
> be... handy?  I can find no real references on krb5_crypto_us_timeofday()
> other than a select set of developer comments within the source code, and a
> whole bunch of spam advertising sites representing it and other source code
> segments?
> 
> On Thu, Apr 2, 2020 at 10:09 PM Benjamin Kaduk  wrote:
> 
> > On Thu, Apr 02, 2020 at 09:04:33PM -0600, Todd Grayson wrote:
> > > Is this some form of specialized unix epoch time timestamp or something?
> > > And more importantly... why?  How do I convert it, normal epoch time
> > > conversion is yielding insane values.
> >
> > It looks to just be the seconds.microseconds output from
> > krb5_crypto_us_timeofday().
> >
> > -Ben
> >
> 
> 
> -- 
> Todd Grayson
> Principal Customer Operations Engineer
> Security SME
> 
> Kerberos mailing list   Kerberos@mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: What form is the timestamp in the KRB5_TRACE log (and why)

[Benjamin Kaduk]

On Thu, Apr 02, 2020 at 09:04:33PM -0600, Todd Grayson wrote:
> Is this some form of specialized unix epoch time timestamp or something?
> And more importantly... why?  How do I convert it, normal epoch time
> conversion is yielding insane values.

It looks to just be the seconds.microseconds output from
krb5_crypto_us_timeofday().

-Ben

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Decrypt integrity check failed while getting initial ticket

[Benjamin Kaduk]

Answering only the unimportant part for lack of insight on the other one...

On Mon, Dec 09, 2019 at 10:04:17AM -0800, Stephen Carville (Kerberos List) 
wrote:
> Recently I migrated the kerberos master and one slave to another 
> location using tool called "Zerto".  Perhaps coincidentally, replication 
> broke with the above error message. I checked that DNS A and PTR records 
> for all the servers are correct.  I can get a ticket using kinit (kinit 
> -k host/). I finally recreated the keytab file 
> (/etc/krb5.keytab) and propagated it to the other three servers.  Still 
> no replication.
> 
> Any suggestions?
> 
> BTW, while trying to fix it, I noticed that every time I use ktadd to 
> add a key to krb5.keytab the KVNO increments.  Is that normal?

Yes, that is normal.  Otherwise any administrator with "extract keytab"
permissions could ~silently fetch the currently in-use keys for a service
and start decrypting or forging traffic; requiring a kvno increment (and
new random key) makes the operation more noticeable and prevents the
exfiltration of the live, in-use, key material.

-Ben

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Installing SAP on Linux snckrb5.so unable to compile.

[Benjamin Kaduk]

On Fri, Aug 02, 2019 at 01:49:15AM +0200, Nitin Salunkhe wrote:
> Hello
> 
> I am facing same error as per group question open by Vusa Moyo can you
> please help me with solution

Are you referring to the post from that individual back from 2006?  Any
insight gained at that time is unlikely to remain current.

Since you provided no details about the sources or makefile you are
attempting to build with, I cannot comment on the details thereof.  That
said, my research while producing https://github.com/kaduk/osxsnc led me to
believe that SAP is quite happy to accept a libgssapi_krb5.so directly as a
SNC adapter (barring the ABI issue on macOS that led to that project).  So
I'm not entirely certain why you need to build anything at all, on linux.

-Ben

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Master-master deployment?

[Benjamin Kaduk]

LDAP is the only builtin KDC backend that supports multi-master KDCs at
all.  (I don't know whether there are any public out-of-tree backends that
do so.)

So, while you could use the LDAP backend with a single LDAP master and
multiple KDC masters, that master LDAP server would be a SPOF.

-Ben

On Sat, Feb 02, 2019 at 01:45:44PM -0500, Yegui Cai wrote:
> Would it be possible to not leverage ldap for multiple-master deployment?
> 
> On Sat, Feb 2, 2019 at 1:14 PM Benjamin Kaduk  wrote:
> 
> > Most of the instances I've heard about that use multi-master KDCs also use
> > multi-master LDAP replication, to avoid the SPOF.
> >
> > -Ben
> >
> > On Sat, Feb 02, 2019 at 11:12:33AM -0500, Yegui Cai wrote:
> > > Hi Thor.
> > > So you have a shared ldap? If so, could that ldap be a single point of
> > > failure?
> > >
> > > Thanks,
> > > Yegui
> > >
> > > On Sat, Feb 2, 2019 at 11:10 AM t Seeger  wrote:
> > >
> > > > Hey Yegui,
> > > >
> > > > I use a mutli master setup. For the sync I use openldap.
> > > >
> > > > Greeting Thor
> > > >
> > > > On 2. Feb 2019, at 15:38, Yegui Cai  wrote:
> > > >
> > > > Hi all.
> > > > I know the official document recommend master-slave deployment for
> > > > production environment.
> > > > Wonder if any try to do a master-master deployment? If yes, how could
> > you
> > > > sync between two masters?
> > > > Thanks,
> > > > Yegui
> > > >
> > > > 
> > > > Kerberos mailing list   Kerberos@mit.edu
> > > > https://mailman.mit.edu/mailman/listinfo/kerberos
> > > >
> > > >
> > > 
> > > Kerberos mailing list   Kerberos@mit.edu
> > > https://mailman.mit.edu/mailman/listinfo/kerberos
> >

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Master-master deployment?

[Benjamin Kaduk]

Most of the instances I've heard about that use multi-master KDCs also use
multi-master LDAP replication, to avoid the SPOF.

-Ben

On Sat, Feb 02, 2019 at 11:12:33AM -0500, Yegui Cai wrote:
> Hi Thor.
> So you have a shared ldap? If so, could that ldap be a single point of
> failure?
> 
> Thanks,
> Yegui
> 
> On Sat, Feb 2, 2019 at 11:10 AM t Seeger  wrote:
> 
> > Hey Yegui,
> >
> > I use a mutli master setup. For the sync I use openldap.
> >
> > Greeting Thor
> >
> > On 2. Feb 2019, at 15:38, Yegui Cai  wrote:
> >
> > Hi all.
> > I know the official document recommend master-slave deployment for
> > production environment.
> > Wonder if any try to do a master-master deployment? If yes, how could you
> > sync between two masters?
> > Thanks,
> > Yegui
> >
> > 
> > Kerberos mailing list   Kerberos@mit.edu
> > https://mailman.mit.edu/mailman/listinfo/kerberos
> >
> >
> 
> Kerberos mailing list   Kerberos@mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Confusion about delegation

[Benjamin Kaduk]

On Fri, Feb 01, 2019 at 02:54:39PM -0500, John Byrne wrote:
> Thanks, this helps a lot.
> 
> I think the reason it appeared to be working for me when I used the wrong
> name HTTP/www.example.com is because I incorrectly had that principal in
> the keytab of the other service. An in the second case, where I omitted the
> creds altogether, you are correct, it just authenticated as HTTP/
> www.example.com and not kerbtestjohn.
> 
> So, I have set ok_to_auth_as_delegate in my KDC for the intermediate
> service principal HTTP/www.example.com, but now I'm getting this error on
> the step() call:
> 
> Feb 01 14:47:14 localhost.localdomain krb5kdc[6376](info): TGS_REQ (8
> etypes {18 17 20 19 16 23 25 26}) 192.168.0.22: NOT_ALLOWED_TO_DELEGATE:
> authtime 0,  HTTP/www.example@example.com for HTTP/
> datastore.example@example.com, Plugin does not support the operation
> 
> I couldn't find any info on this, but I did some reading in the source code
> and it looks like the necessary function 'check_allowed_to_delegate' is
> only defined for the ldap plugin. Have I got that right - I have to use
> ldap to get this feature to work with the krb5 server? Or is there another
> way?

The only in-tree module that supports constrained elegation, yes.  (At
least one out-of-tree module also exists, though presumably you would
already know if that was one you wanted.)

-Ben

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: reporting bugs

[Benjamin Kaduk]

On Tue, Nov 13, 2018 at 03:29:08PM +, Toby Blake wrote:
> Hi,
> 
> Is mailing krb5-b...@mit.edu still the correct way to report bugs, as a
> front-end into the RT system, as described here:?

Yes.

> https://web.mit.edu/kerberos/mail-lists.html
> 
> I ask because I mailed krb5-bugs last Friday, but my message doesn't
> seem to have made it into either the archives or http://krbdev.mit.edu/rt
> (although I only have guest access to the latter, so may not be seeing
> all).

Incoming mail gets held for moderation in case the bug being reported has
security consequences.  Moderation being a manual process, sometimes this
sort of delay is possible.  (I don't have access to the moderation queue,
myself.)

-Ben

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Make Windows Firefox Use Ticket gained via OpenConnect VPN Connection

[Benjamin Kaduk]

The description of current and desired behavior is a bit sparse, but it
seems like the key question is whether/where openconnect stores the
kerberos ticket obtained during VPN connection.  If it's stored someplace
accessible, the rest would just be a matter of getting the different tools
plumbed together properly.  But if the KfW ticket manager does not show any
credentials after the openconnect login, it may be that openconnect is not
storing the ticket anywhere, in which case a software change would be
needed to openconnect to get it to do so.

-Ben

On Sat, Oct 20, 2018 at 10:09:57PM +0200, chiasa.men wrote:
> I have an openconnect server where I can login with kerberos credentials (the 
> vpn server basically also works as proxy to the kdc within said vpn - more 
> detailed description: https://access.redhat.com/blogs/766093/posts/1976663)
> 
> Now I can connect with a windows machine (using openconnect-gui) with my 
> kerberos credentials. Which works.
> 
> The next step shall be to use the gained ticket further for webservices 
> within 
> that vpn. How can I tell the browser (e.g. Firefox) to use the ticket gained 
> by openconnect? Is there any way to achieve this?
> 
> I also installed the MIT Kerberos Ticket Manager for Windows. Here (https://
> community.hortonworks.com/content/kbentry/28537/user-authentication-from-
> windows-workstation-to-hd.html) is desribed that it is possible to use that 
> Manager with firefox in order to authenticate to webservices. Although I 
> haven't been able to accomplish that, would it be possible to tell MIT 
> Kerberos Ticket Manager to use the Ticket of the vpn login?
> 
> Is there already a 'usual way' to achieve something like sso via vpn with 
> kerberos with windows clients?
> 
> 
> 
> 
> 
> Kerberos mailing list   Kerberos@mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: MIT Kerberos client and default cache

[Benjamin Kaduk]

On Tue, Oct 16, 2018 at 09:40:42AM +0200, Pierre Dehaen wrote:
> Hello list,
> 
> Configuration:
> - Windows are clients of an AD
> - Kfw 4.1 is used to acquire tickets from another realm
> - Clients use tickets through Firefox to access apache applications
> - All working well
> 
> In the Kfw GUI, next to the TGT of the additional realm, we see the TGT of 
> the AD. The 
> former shows API: as credential cache, while the later shows MSLSA:, all good.
> 
> According to 
> : Once 
> you have a ticket, the "make default" button will set the registry entry for 
> you. 
> 
> That is the problem: once a user has clicked "Make default" while the AD 
> ticket was by 
> chance selected, only one TGT can be acquired at a time, each Get Ticket 
> overwrites all 
> existing tickets.
> 
> Okay, I can fix this in the registry... but users can't, that's too 
> difficult/risky, and I don't find a 
> way to revert to the default credential cache from the GUI. Even the "Make 
> default" trick does 
> not work anymore as all tickets are MSLSA tickets.
> 
> Any advice?

Sadly, this is a "patches welcome" moment -- the issue has been known for
several years but has not been a development priority.  The best workaround
would be to clear the registry entry (and presumably you could prepare a
script/standalone tool to clear this specific registry key, that would be
safe for exposure to end users).

-Ben

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: issue with k5start

[Benjamin Kaduk]

Ah, I see.

The needed changes would seem to be in the OpenAFS client software,
to have the logic to update to using a new token (if available) when
the current one is close to expiry, and in the AFS server software to
issue a fresh challenge when the client's credential is expiring
(instead of just aborting the connection).  And rxgk is probably a
higher priority for OpenAFS at the moment...

-Ben

On Tue, Oct 09, 2018 at 10:46:34PM -0600, Kristen Webb wrote:
> Hi Ben,
> Thank you for the comment.  We have always used -localauth on the backup
> server with cell keys,
> and even multiple cell keys for multiple cells to do just that.  We are
> migrating to
> kerberos principals so that the cell keys are not required on our backup
> servers.
> Mostly for security reasons.
> 
> On Tue, Oct 9, 2018 at 7:07 PM Benjamin Kaduk  wrote:
> 
> > Hi Kristen,
> >
> > I think I missed some of the thread, but I'll note that the token used by
> > 'vos dump -localauth' never expires.
> >
> > -Ben
> >
> > On Mon, Oct 08, 2018 at 02:15:11PM -0600, Kristen Webb wrote:
> > > Hi Everyone,
> > >
> > > Thank you all for the online and offline responses.  Unfortunately, as I
> > > have learned,
> > > k5start or any other mechanism will not keep a vos dump moving beyond the
> > > inital
> > > lifetime grated to the token controlled by the kerberos configuration.
> > So,
> > > for example,
> > > if I want a 1 week lifetime for very long running jobs as tibs@REALM I
> > need
> > > to set:
> > >
> > > 1. In kdc.conf or equivalent:
> > >
> > > max_life = 168h 0m 0s
> > >
> > > 2. Set all the appropriate max lifetimes in the KDB (modprinc -maxlife
> > > 168hours)
> > >
> > > krbtgt/REALM
> > > backup_admin@REALM
> > > afs/cell@REALM
> > >
> > > Then kinit/aklog is sufficient, k5start is nice for dealing with CCACHE
> > > names, but will
> > > not keep things running any longer.  Someone mentioned GSSproxy.  I have
> > > not had
> > > time to look at this closer, but I suspect it may not help with the vos
> > > command in particular.
> > >
> > > Kris
> > >
> > >
> > > On Tue, Sep 25, 2018 at 3:11 PM Russ Allbery  wrote:
> > >
> > > > Kristen Webb  writes:
> > > >
> > > > > When I use the -k ccache option it appears that each job simply
> > > > > overwrites the cchache file.
> > > >
> > > > It should only do this if the ticket is going to expire sooner than two
> > > > minutes before the next wake-up period, though, I think?  I would have
> > > > expected this to work with all jobs sharing the same cache file, as
> > long
> > > > as they're at least a little staggered.  That said, I don't think I've
> > > > really tested for this sort of parallelism, and it's entirely possible
> > > > that the separate k5start processes don't manage coordination between
> > each
> > > > other on the same ticket cache properly.
> > > >
> > > > > Is there a way to use k5start to achieve what I am after
> > > > >  - shared ccache for many jobs to keep kerberos server traffic
> > down
> > > > >  - allow long running jobs to continue beyond their initial aklog
> > > > > renewal date
> > > >
> > > > > If I ran k5start as a daemon and managed periodic aklog's within my
> > > > > application, would that work?
> > > >
> > > > Yes, that's what I was going to suggest.  If each application is
> > running
> > > > in a separate PAG, each application needs to run aklog periodically
> > > > independently of the others.  If you also want to share a single ticket
> > > > cache among the applications, you probably want to split those two
> > > > operations.
> > > >
> > > > Unfortunately, k5start doesn't currently have a mode of operation in
> > which
> > > > it only runs the aklog command but doesn't try to renew tickets if they
> > > > aren't about to expire.
> > > >
> > > > --
> > > > Russ Allbery (ea...@eyrie.org)  <
> > http://www.eyrie.org/~eagle/>
> > > >
> > >
> > >
> > > --
> > > This message is NOT encrypted
> > > 
> > > Mr. Kristen J. Webb
> > > Chief Technology Officer
> >

Re: issue with k5start

[Benjamin Kaduk]

Hi Kristen,

I think I missed some of the thread, but I'll note that the token used by
'vos dump -localauth' never expires.

-Ben

On Mon, Oct 08, 2018 at 02:15:11PM -0600, Kristen Webb wrote:
> Hi Everyone,
> 
> Thank you all for the online and offline responses.  Unfortunately, as I
> have learned,
> k5start or any other mechanism will not keep a vos dump moving beyond the
> inital
> lifetime grated to the token controlled by the kerberos configuration.  So,
> for example,
> if I want a 1 week lifetime for very long running jobs as tibs@REALM I need
> to set:
> 
> 1. In kdc.conf or equivalent:
> 
> max_life = 168h 0m 0s
> 
> 2. Set all the appropriate max lifetimes in the KDB (modprinc -maxlife
> 168hours)
> 
> krbtgt/REALM
> backup_admin@REALM
> afs/cell@REALM
> 
> Then kinit/aklog is sufficient, k5start is nice for dealing with CCACHE
> names, but will
> not keep things running any longer.  Someone mentioned GSSproxy.  I have
> not had
> time to look at this closer, but I suspect it may not help with the vos
> command in particular.
> 
> Kris
> 
> 
> On Tue, Sep 25, 2018 at 3:11 PM Russ Allbery  wrote:
> 
> > Kristen Webb  writes:
> >
> > > When I use the -k ccache option it appears that each job simply
> > > overwrites the cchache file.
> >
> > It should only do this if the ticket is going to expire sooner than two
> > minutes before the next wake-up period, though, I think?  I would have
> > expected this to work with all jobs sharing the same cache file, as long
> > as they're at least a little staggered.  That said, I don't think I've
> > really tested for this sort of parallelism, and it's entirely possible
> > that the separate k5start processes don't manage coordination between each
> > other on the same ticket cache properly.
> >
> > > Is there a way to use k5start to achieve what I am after
> > >  - shared ccache for many jobs to keep kerberos server traffic down
> > >  - allow long running jobs to continue beyond their initial aklog
> > > renewal date
> >
> > > If I ran k5start as a daemon and managed periodic aklog's within my
> > > application, would that work?
> >
> > Yes, that's what I was going to suggest.  If each application is running
> > in a separate PAG, each application needs to run aklog periodically
> > independently of the others.  If you also want to share a single ticket
> > cache among the applications, you probably want to split those two
> > operations.
> >
> > Unfortunately, k5start doesn't currently have a mode of operation in which
> > it only runs the aklog command but doesn't try to renew tickets if they
> > aren't about to expire.
> >
> > --
> > Russ Allbery (ea...@eyrie.org)  
> >
> 
> 
> -- 
> This message is NOT encrypted
> 
> Mr. Kristen J. Webb
> Chief Technology Officer
> Teradactyl LLC.
> 2450 Baylor Dr. S.E.
> Albuquerque, New Mexico 87106
> Phone: 1-505-338-6000
> Email: kw...@teradactyl.com
> Web: http://www.teradactyl.com
> 
> 
> 
> Providers of Scalable Backup Solutions
>for Unique Data Environments
> 
> 
> NOTICE TO RECIPIENTS: Any information contained in or attached to this
> message is intended solely for the use of the intended recipient(s). If
> you are not the intended recipient of this transmittal, you are hereby
> notified that you received this transmittal in error, and we request
> that you please delete and destroy all copies and attachments in your
> possession, notify the sender that you have received this communication
> in error, and note that any review or dissemination of, or the taking of
> any action in reliance on, this communication is expressly prohibited.
> 
> 
> Regular internet e-mail transmission cannot be guaranteed to be secure
> or error-free. Therefore, we do not represent that this information is
> complete or accurate, and it should not be relied upon as such. If you
> prefer to communicate with Teradactyl LLC. using secure (i.e., encrypted
> and/or digitally signed) e-mail transmission, please notify the sender.
> Otherwise, you will be deemed to have consented to communicate with
> Teradactyl via regular internet e-mail transmission. Please note that
> Teradactyl reserves the right to intercept, monitor, and retain all
> e-mail messages (including secure e-mail messages) sent to or from its
> systems as permitted by applicable law
> 
> Kerberos mailing list   Kerberos@mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: compile KDC with KKDCP support

[Benjamin Kaduk]

On Tue, Aug 28, 2018 at 05:16:40PM +, Jim Shi wrote:
> Hi, Robbie,
> I got trace after using a file. Looks the client is not recognizing kdc = 
> https://...
> Instead it thinks the host name is 'https'.  
> I compile KDC client with recent code.
> What could be missing in KDC client?

Sorry for repeating the simple/obvious questions, but have you
double-checked (e.g., via PATH and ldd) that you are running the code you
think you are?

-Ben

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: MIT Kerberos for Windows failing with Windows 10 update 1803?

[Benjamin Kaduk]

On Mon, Jun 18, 2018 at 05:31:33PM -0400, Greg Hudson wrote:
> On 06/18/2018 12:25 PM, Ruurd Beerstra wrote:
> > I probably should have mentioned I tried setting the ccache type to
> > "FILE", and that didn't work either.
> 
> Just "FILE"?  You need to set it to "FILE:pathname" for some pathname.
> 
> I don't have a hypothesis to explain why "API:" wouldn't work.  I 
> updated a Windows 10 VM to 1803 and installed the kfw 4.1 MSI.  With the 
> API: ccache type I was able to acquire tickets, renew tickets, acquire 
> service tickets using kvno, and see the acquired service ticket with klist.
> 
> With the MSLSA: ccache type it does seem like I can't access the TGT 
> session key.  I can acquire a TGT and can view it in the graphical 
> ticket manager (but not with klist; not sure why).  Renewing the TGT 

I think the magic there is at
https://github.com/krb5/krb5/blob/master/src/windows/leash/KrbListTickets.cpp#L201

> doesn't appear to work, although I only see an error message if I run 
> "kinit -R" from the command line (same error as you saw, "Matching 
> credential not found"); with the graphical ticket manager it seems to 
> silently fail.  I can obtain a service ticket and view that with klist, 
> but from tracing output it is clear that that is happening through the 
> LSA (which is probably able to find the realm I'm testing against using 
> SRV records in DNS).

My recollection was that you needed something in the registry (at
the path I mentioned in my previous mail) even to get the LSA to
look for SRV records.  (Do I know what realm you're testing with?)
IIRC the KfW installer does prepopulate KDC entries for a couple of
realms, as an example if nothing else.)

-Ben

> > A quick search on Credential Guard says: The Windows Defender Credential
> > Guard prevents these attacks by protecting NTLM password hashes,
> > Kerberos Ticket Granting Tickets, and credentials stored by applications
> > as domain credentials.
> 
> To be clear, my uncomfirmed hypothesis is that update 1803 made the 
> HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos AllowTGTSessionKey 
> registry variable inoperable, with or without Credential Guard.  An 
> additional restriction on access to service ticket session keys does not 
> seem to match the errors you're seeing.
> 
> Kerberos mailing list   Kerberos@mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: MIT Kerberos for Windows failing with Windows 10 update 1803?

[Benjamin Kaduk]

On Sun, Jun 17, 2018 at 04:35:50PM -0400, Greg Hudson wrote:
> On 06/17/2018 02:02 PM, Ruurd Beerstra wrote:
> > The symptoms are that I can obtain a TGT from my KDC (which ends up in
> > de LSA of Windows), but every attempt to use that TGT to obtain a
> > service ticket yields an error:
> > Matching credential not found.
> 
> Unfortunately, our mailing list server doesn't pass through attachments, 
> so while I briefly saw your screenshots before moderating through your 
> message, they didn't make it to the list (and I didn't keep a copy.)
> 
> I believe the correct short answer is to use the "API:" ccache instead 
> of the "MSLSA:" ccache for this setup.
> 
> For some time Windows has restricted access to TGT session keys in the 
> LSA, which means our libkrb5 code can't use a TGT from the LSA to get 
> service tickets.  Instead, our MSLSA ccache type requests service 
> tickets via Windows, but that only works if the realm is set up in the 
> LSA configuration.  Since you are using an MIT krb5 KDC, I am guessing 
> that it is not set up in the LSA configuration, so we fall back to 
> trying to get service tickets using the TGT.

Does this mean that you think setting the appropriate entries under
SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Domains would resolve
the issue?

-Ben

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Question about TGT forwarding

[Benjamin Kaduk]

On Wed, Jun 06, 2018 at 05:08:19PM -0400, Jason Edgecombe wrote:
> 
> Running "klist" when logged on to Windows 10 with my domain account shows
> the following flags for my krbtgt/DOMAIN entry:
> 
> Ticket Flags 0x60a1 -> forwardable forwarded renewable pre_authent
> name_canonicalize

That's the windows-native klist binary -- it might be interesting to
see the KfW klist output, which you can get if you run it with the
full path (e.g., C:\Program Files\MIT\Kerberos\bin\klist.exe IIRC)

-Ben

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Question about TGT forwarding

[Benjamin Kaduk]

On Thu, May 31, 2018 at 04:50:36PM -0400, Jason Edgecombe wrote:
> Hi everyone,
> 
> We're noticing some odd behaviour on our Windows clients where the Windows
> clients are not forwarding the TGT to our Linux servers. People can login
> to the Linux servers from windows clients, but "klist" shows no tickets
> after login. Linux clients forward the TGT just fine. In case it matters,
> we just moved our Linux home directories from a NAS with Kerberized SMB to
> a Linux NFS server with Kerberized NFS. I've had to disable GSSAPI
> authentication in openssh so that windows users can still get tickets on
> the remote end.

The use of "GSSAPI authentication" seems to imply that a third-party
(i.e., not native WindowS) Kerberos implementation is in use.  If
so, which implementation, and which credentials cache type?

> I have a disagreement with our AD guru on whether or not TGTs are expected
> to be forwarded and if that is a security risk. Everything worked fine a
> few weeks ago.

The Windows behavior has changed from release to release; at some
points TGTs in the Windows-native "LSA" cache were retrievable only
for users that were not (local) Administrators.  At this point the
limitation may apply to all users, though; I have lost track.

Regardless, the behavior of the Windows LSA should only be relevant
if the Windows-native credentials are being used.  With a Heimdal or
MIT KfW implementation, an external tool could be used to obtain
tickets outside of the LSA and use those for GSSAPI
authentication+delegation, the same as on Linux.

-Ben

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: kkdcp

[Benjamin Kaduk]

On Thu, May 24, 2018 at 10:01:10PM +, Jim Shi wrote:
> Does MIT KDC support kkdcp? Which version is required to support kkdcp?

https://web.mit.edu/kerberos/krb5-latest/doc/mitK5features.html#feature-list

Release 1.13

Add support for accessing KDCs via an HTTPS proxy server using the
MS-KKDCP protocol.


Note that this is only client-side support; there's no KDC-side
support AFAIK.  (This functionality could be implemented as a
standalone proxy, of course.)

-Ben

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: KRB5_TRACE does not work on csh

[Benjamin Kaduk]

On Tue, May 15, 2018 at 06:30:20PM +0200, Meike Stone wrote:
> Hello,
> 
> maybe it is a stupid question and not a kerberos problem, but I can't
> get KRB5_TRACE working in a csh.
> 
> On Bash it works as expected:
> export KRB5_TRACE=/dev/stdout
> echo $KRB5_TRACE
> /dev/stdout
> 
> kinit me...@test.net
> [22698] 1526401109.124271: Getting initial credentials for me...@test.net
> [22698] 1526401109.124373: Sending request (144 bytes) to TEST.NET
> [22698] 1526401109.124457: Resolving hostname kdc1
> [22698] 1526401109.125178: Sending initial UDP request to dgram 
> 192.168.1.100:88
> [22698] 1526401109.127098: Received answer (168 bytes) from dgram
> 192.168.1.100:88
> [22698] 1526401109.127909: Response was not from master KDC
> [22698] 1526401109.127930: Received error from KDC:
> -1765328359/Additional pre-authentication required
> [22698] 1526401109.127962: Processing preauth types: 16, 15, 19, 2
> [22698] 1526401109.127974: Selected etype info: etype aes256-cts, salt
> "TEST.NETmeike", params ""
> Password for me...@test.net:
> 
> 
> on /bin/csh (a link to /bin/tcsh):
> setenv KRB5_TRACE /dev/stdout
> echo $KRB5_TRACE
> /dev/stdout
> 
> kinit me...@test.net
> Password for me...@test.net:
> 
> 
> What is the problem here.

A guess, maybe there is special /dev/stdout handling involved.  A
test using a file on an actual filesystem might be worth doing.

-Ben

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: /etc/default/krb5-admin-server: 'RUN_KADMIND=false' not possible anymore

[Benjamin Kaduk]

On Fri, Apr 20, 2018 at 11:22:03AM +0100, Giuseppe Mazza wrote:
> Dear All,
> 
> I want to install a new kerberos slave running on Ubuntu16.04.
> I would like to prevent the service  krb5-admin-server running on the slave.
> 
> It seems to me that is not possible to set the variable 
> 'RUN_KADMIND=true' in /etc/default/krb5-admin-server anymore.
> 
> I wonder if you could advice about the best way to do it.

That's a Debian/Ubuntu-specific configuration file, so you should
file a bug at Ubuntu (or Debian, if you know it also applies there).

Does the behavior change perhaps coincide with a change of init
implementation?

-Ben

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: krb5_verify_user

[Benjamin Kaduk]

On Tue, Jan 09, 2018 at 08:23:41PM +, Imanuel Greenfeld wrote:
> Thank you Ben.
> 
> I managed to use krb5_init_creds_password(), krb_verify_init_creds() and
> krb5_get_credetials() and each returned 0 so I'm assuming that's ok.
> 
> How do I now send a message to the server ?  I found krb5_sendauth() - do
> you have a simple example how to use this function ?

What is "the server"?  How you send a message to it depends on what
protcol you need to speak to it.

For new protocols, we generally recommend using the GSSAPI instead
of krb5_sendauth() or similar.

-Ben

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: krb5_verify_user

[Benjamin Kaduk]

On Mon, Jan 08, 2018 at 09:49:06PM +, Imanuel Greenfeld wrote:
> Hello,
> 
>  
> 
> Hope you're well.
> 
>  
> 
> Happy new year.
> 
>  
> 
> I am looking for krb5_verify_user function under krb5/krb5.h and in fact
> anywhere but cannot find it.
> 
>  
> 
> I know it's not recommended to use it with the password, but I want to see
> if I can prove the point.
> 
>  
> 
> I am therefore getting compilation error for the function needing a
> prototype.
> 
>  
> 
> I'm using 1.16 and also tried on 1.15.2
> 
>  
> 
> Any ideas please ?

krb5_verify_user() is a function in the Heimdal implementation of
Kerberos, but is not present in MIT krb5.

Upon cursory examination, it seems that
krb5_get_init_creds_password() and krb5_verify_init_creds() together
might be a suitable replacement.  Note that it requires the caller
to have access to a service keytab (and the principal name must be
specified if it is not host/).

-Ben

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Kerberos and REST

[Benjamin Kaduk]

On Fri, Dec 08, 2017 at 06:39:56AM +, Imanuel Greenfeld wrote:
> Thank you Ben for the information.
> 
> I downloaded Kerberos .gz from your web site and built the libraries.
> 
> I'm looking at sclient and sserver. 
> 
> When I run sclient with   then I'm getting
> Connected.
> 
> But when I run sserver nothing happens.
> 
> Any ideas what I'm doing wrong please ?

If you want to use sserver as an example and familiarize yourself
with how things work, starting with its manual page seems
reasonable:
http://web.mit.edu/kerberos/krb5-latest/doc/admin/admin_commands/sserver.html

-Ben

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Kerberos and REST

[Benjamin Kaduk]

It sounds like you are trying to come up with a scheme where the
user credentials are transmitted to this REST server, and the REST
server then uses the user's credentials to authenticate some backend
requests made by the REST server while processing the body of the
REST request.  This is, in effect, trusting the REST server to
not misabuse the user's credentials that are given to it with the
request.

There are some technical means that can somewhat reduce the scope of
the user's credentials that are transmitted (please, please, please
do not transmit the raw password!), but it may be worth taking a
step back and questioning whether the user's credentials are really
needed.  That is, if the REST service is sufficiently trusted to be
allowed to handle user credentials, why could it not have
credentials of its own that are then used to authenticate the
backend requests?  That would eliminate the need for the actual
user's credentials to be given to the REST server, which is probably
more secure for the user.

There are potentially fancier mechanisms that could be used that do
not directly give the REST server full authorization and instead
require it to present proof that the user has authenticated to it,
before being granted the needed tightly scoped credential by yet
another service.  But it's not clear that such complications are
really needed -- from what you describe, it might be fine to give
the REST server its own kerberos credentials and just use that to
authenticate backend requests.

-Ben

On Thu, Dec 07, 2017 at 07:21:16AM +, Imanuel Greenfeld wrote:
>  
> 
> Hello
> 
>  
> 
> I am a C++ developer working on a project in industry.
> 
>  
> 
> I have a Windows client which the user submits requests with.
> 
>  
> 
> These requests are then sent to a backend process running in the background
> on Sun Solaris waiting to process those requests.
> 
>  
> 
> I then need to take each of those requests and authenticate using Kerberos
> to gain access to a different server to get a response.
> 
>  
> 
> Once I go through the Kerberos authentication, I need to submit a JSON
> message using REST.  For this I'm using gSoap.
> 
>  
> 
> Reading about Kerberos it seems that the client needs to get the Token and
> then send with the private encrypted password.  However, the problem is that
> once the request been submitted from the user, the client is out of the
> picture - I cannot send anything back to it or store anything in it.
> 
>  
> 
> I am hoping that I can send the REST call along with the Kerberos
> authentication in one go.  For example :- 
> 
>  
> 
>.
> 
>soap *ctx = soap_new1(SOAP_C_UTFSTRING);  // set up context
> to manage memory
> 
>   const char *endpoint = "https://...;;
> 
>   value req(ctx), res(ctx); // new JSON values req and res
> 
>   req = "getCurrentTime";   // request current time
> 
>   json_call(ctx,// make a call (POST)
> 
>   endpoint, // the service endpoint URL
> 
>   req,  // value with the request string
> 
>   res)  // response, if call is OK
> 
>   );
> 
> .
> 
>  
> 
> So, in  json_call I'd like to incorporate in the ctx the Kerberos
> authentication.
> 
>  
> 
> Is that possible ? 
> 
>  
> 
> Any other suggestions please ?
> 
>  
> 
> Do you have any C++ examples showing how to implement Kerberos ?
> 
>  
> 
> Many thanks in advance.
> 
>  
> 
> Imanuel.
> 
>  
> 
> 
> Kerberos mailing list   Kerberos@mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Linux ksu (kerberized super user) command fails to use cached service (host) tickets... how can I do this?

[Benjamin Kaduk]

On Thu, Nov 09, 2017 at 11:10:12AM +0100, Fabiano Tarlao wrote:
> 
>- is there a way to populate a Kerberos cache file with a service ticket
>(for the host) that is compatible with *ksu*?
>- I have read about *kvno*
>
>command but I have failed to use it, the documentation does not suffice
>(for me) and there are no usage examples around, can you explain me how to
>use it?

kvno is a simple tool that attempts to perform a TGS request for a ticket
for the indicated service principal, and reports the key version number
of that service principal used by the KDC to encrypt the ticket.
It requires a TGT to be present in the cache already, so you would do
your normal kinit, and then `kvno HOST/authdemo4.addemo...@addemo.it`.

>- Are there alternatives to *kvno* command in order to perform service
>ticket requests to TGS (and put it into a cache file)?

Not really.  That is, there are lots of things that will request a
service ticket and put it in the cache as part of their normal operation
(ssh, ldapsearch, etc.), but kvno is the closest to a dedicated tool
for this operation.

>- Am I doing something wrong? Any tip?

My only guess is that ksu is being confused the the 'initial' service
ticket (i.e., obtained directly from the AS and not the TGS), so that
kinit+kvno would help.  But the ksu codebase is not much fun to go
looking in, so I did not try to check.

-Ben

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: PID file ... not readable (yet?)

[Benjamin Kaduk]

On Sun, Nov 05, 2017 at 09:57:30AM -0500, Greg Hudson wrote:
> On 11/05/2017 05:36 AM, Jaap Winius wrote:
> >systemd[1]: krb5-kdc.service: PID file /run/krb5-kdc.pid \
> >  not readable (yet?) after start: No such file or directory
> 
> Does everything seem to work aside from this warning message being
> produced, or is there an accompanying problem?
> 
> There can be a very brief window of time between krb5kdc exiting on
> startup and its child process writing the pid file.  That window is
> normal for traditional Unix daemon programs (because of the way the
> daemon() function works) and isn't a problem as long as nothing wants to
> restart the KDC service in the first second of its life.  But it might
> be enough for systemd to complain.

I'd also add that Jaap (and everyone) should feel free to file Debian
bugs for issues, especially with the systemd configuration, since that
comes from the Debian packaging and is not part of upstream.  (That said,
it's certainly not wrong to ask about it here.)

I suspect that we would be a little friendlier to systemd if we passed
-n to krb5kdc and adjusted the unit file accordingly.  There would still
be a race window between when systemd thinks krb5kdc is started and
ready to accept connections and when that is actually the case, but
in both cases that window is small, and we cannot eliminate it entirely
without patching the code to call systemd-specific functions.

-Ben

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: MIT Kerberos OTP with Windows

[Benjamin Kaduk]

On Mon, Oct 30, 2017 at 09:05:10AM -0700, Pallissard, Matthew wrote:
> > any ideas how to implement OTP for Windows with MIT kerberos client? 
> > possible?
> 
> I don't know if KFW 4.1 supports OTP but what I do know is that in the past I 
> couldn't get PKINIT working with KFW. I had to implement heimdal on the 
> client end.
> 
> https://www.mail-archive.com/kfwdev@mit.edu/msg00822.html
> 
> Could be related.  Someone here could probably speak to that better than 
> myself though.

It's quite related, yes.

The FAST OTP mechanism of RFC 6560 requires a FAST tunnel to exist over
which the OTP value is sent.  Generally this tunnel is obtained via
anonymous PKINIT, but PKINIT of all forms is not currently implemented
in KfW.  In principle, the needed FAST tunnel could be obtained in
other ways, e.g., via a machine keytab, but the number of situations
in which these other methods would actually be useful are quite limited.

-Ben

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: How install / build mit-krb5?

[Benjamin Kaduk]

On Thu, Oct 19, 2017 at 10:12:21PM +0200, Andy wrote:
> I need directory /usr/lib/x86_64-linux-gnu/mit-krb5 with .so and
> /usr/include/mit-krb5 with .h.
> I have installed:
> apt-get -y install krb5-user libcomerr2
> apt-get install krb5-kdc

apt-get install libkrb5-dev

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: krb5

[Benjamin Kaduk]

On Tue, Oct 17, 2017 at 03:04:20PM -0700, Earl Killian wrote:
> So obviously I removed the two new "security" lines from my krb5.conf to
> restore things to a working situation. However, I would like to inquire
> of the mailing list how things are supposed to work when those are set
> to false as in the openSUSE distro.

Most likely, your system is configured such that (some things) think that
the local hostname is just "alpha", not the fully-qualified form.
So, the output of `hostname` and `hostname -f` are interesting, as is
the contents of /etc/hosts.

-Ben

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Kerberos OTP with FreeRadius

[Benjamin Kaduk]

On Fri, Jul 07, 2017 at 11:04:47AM +0200, Felix Weissbeck wrote:
> 
> The  "problem" hereby is, that you can now obtain a kerberos ticket with your 
> second factor alone; so you could configure PAM to successfully authenticate 
> with password+token. 

Yes, the FAST/OTP preauthentication mechanism from RFC 6560 uses only
the OTP factor, which makes it a great solution if you already have
deployed OTP infrastructure and need to add a kerberos solution for
your site.  For using OTP as a second factor, it's not really an option.

The current thinking in this space is that the SPAKE preauth scheme
in https://datatracker.ietf.org/doc/draft-ietf-kitten-krb-spake-preauth/
will fill this void, allowing a second factor to be mixed in with a
PAKE password-based preauth, that does not expose anything encrypted
in password-based keys directly on the wire (so as to stymie brute-force
attacks).

-Ben

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: wrong key is generated by krb5_c_string_to_key

[Benjamin Kaduk]

On Tue, Jun 06, 2017 at 11:55:23PM -0700, Ashi1986 wrote:
> Thanks for your response.
> 
> >>If so, you might try to apply manually the diff from the commit that
> >>Robbie mentioned already. 
> I am new to open source, can you please share the link from where I can get
> the commit sources.

Sorry for the slow response.

You should be able to save
https://github.com/krb5/krb5/commit/89ce6420832858950271858e7c6e1a2eefebc683.diff
to a file in order to have the patch locally.

What to do with it then depends on how you are currently getting
your kerberos software.  If you are using an OS supplied version (as
from Fedora or Debian), then you would need to download the source
package from that distribution (instead of the binary package you
are currently using), and use that distro's package-building
workflow to apply the extra patch and produce binary packages
containing it (that can then be manually installed).  If, on the
other hand, you are currently compiling kerberos from source, then
you can use the patch(1) utility to apply the downloaded patch and
rebuild quickly.

But more details for any of those methods are probably out of scope
for this mailing list; your OS should have various forums for
support (if you're using OS packages), or there are general
references for building software online.

-Ben

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: wrong key is generated by krb5_c_string_to_key

[Benjamin Kaduk]

On Tue, Jun 06, 2017 at 01:48:58AM -0700, Ashi1986 wrote:
> Thank you very much for the response.
> 
> >manually since its just an md4 hash with no salt, something like:
> ># echo -n password | iconv -t UTF-16LE | openssl dgst -md4
> >And compare with the key in the keytab:
> ># klist -Kekt krb5.keytab 
> 
> I have derived the key manually by using the below command:
> # echo -n password | iconv -t UTF-16LE | openssl dgst -md4
> and the generated key regarding RC4 is same as key generated by KTPASS
> command.
> 
> but the key generated by MIT function krb5_c_string_to_key is different from
> the key generated by KTPASS command.

To confirm, this is the MIT 1.13.2 code that is producing the
inconsistent result?

If so, you might try to apply manually the diff from the commit that
Robbie mentioned already.

-Ben

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Doubts regarding Keytab file

[Benjamin Kaduk]

On Wed, May 10, 2017 at 12:20:44AM +0530, Abhishek Kaushik wrote:
> Thank you for replying.
> 
> I understood that it is a symmetric key which is shared with the KDC.
> So, is it in binary format or is there some other format which is used,
> generally?

The keytab file format is documented at
http://web.mit.edu/kerberos/krb5-latest/doc/formats/keytab_file_format.html

> And what if(hypothetically) you don't have a password for some user, how is
> the key generated in such a case?
> Like you have mentioned that the services only have the raw key..

During provisioning or rekeying, the KDC generates a random key and
transmits it to the client (over an encrypted connection, of
course).

-Ben

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Doubts regarding Keytab file

[Benjamin Kaduk]

On Tue, May 09, 2017 at 01:02:08PM +0530, Abhishek Kaushik wrote:
> Hello,
> 
> I am trying to understand how Kerberos works and so came across this file
> called Keytab which, I believe, is used for authentication to the KDC
> server.
> 
> Just like every user and service(say Hadoop) in a kerberos realm has a
> service principal, does every user and service have a keytab file?
> 
> Also, does authentication using keytab work on symmetric key cryptography
> or public-private key?

For traditional kerberos, each principal (user or service) shares a
symmetric key with the KDC, and the KDC acts as a trusted
third-party for authentication exchanges.  Generally, users will
know this key in the form of a password (there is a fixed
password-to-key function, so the KDC stores the key and not the
password), and service principals will just have the raw shared
key(s).  Such raw shared keys are stored in a keytab file, which is
used both for authentication to the KDC as you note, and also for
decrypting and authentication authentication requests from other
principals to the service in question.

In order to be usable in the (traditional) kerberos ecosystem, each
principal needs at least one of a password and a keytab file.  It's
possible, but rare, to have both present for the same principal.

I have been referring to "traditional kerberos", which is
exclusively symmetric cryptography.  There are certain extensions to
kerberos that use public-key cryptography, most notably PKINIT (RFC
4556), but at present such schemes are only used for the initial
authentication to the KDC; subsequent protocol exchanges and
authentication to other services still use symmetric cryptography.

-Ben

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: kerberos error setup on mac

[Benjamin Kaduk]

You should send a link to the procedure you are trying to follow;
otherwise we cannot help you.  That is, you say "from the website",
but which website?

-Ben

On Thu, Apr 13, 2017 at 10:41:28AM +0800, Ronald Gmail wrote:
> Hello,
> 
> Thanks for your prompt response, however i'm still facing error when 
> compiling the package on mac Sierra OS.
> 
> I had followed the procedure which is quite old one.
> 
> Looks like nautils does not exist on the latest mac version, I did searched 
> and tried dcsl to modified the services, I'm not sure whether there is sign 
> that dscl is working or not.
> 
> Have tried these steps :
> 1. From the website I replaced nautil to dscl.
> 2. Rebooted my mac.
> 3. In the src directory, I excuted configure.
> 4. From the resolve path I did executed ./resolve command.
> 
> Can you help me to direct to the latest link if you have it?
> 
> 
> 
> 
> Thank you,
> 
> > On 13 Apr 2017, at 8:02 AM, Benjamin Kaduk <ka...@mit.edu> wrote:
> > 
> > Hi Ronald,
> > 
> >> On Thu, Apr 13, 2017 at 12:47:36AM +0800, ronald rodriguez wrote:
> >> Hi MIT team,
> >> 
> >> Just need help to install on mac, seems the instruction provided is not 
> >> working on latest mac version, are you able to provide the update steps to 
> >> install the kerberos master on mac osx?
> > 
> > This question is better directed at the public kerberos@mit.edu
> > list, and anyway would require more details to be answerable.  (You
> > write as if there is only one instruction set globally, which is
> > decidedly not true.  You'd need to provide more details about what
> > procedure you are following and how it fails in order for anyone to
> > help you.)
> > 
> > -Ben

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Iterate over server credentials

[Benjamin Kaduk]

On Wed, Mar 22, 2017 at 03:48:21PM -0400, Dylan Klomparens wrote:
> Hello,
> 
> I'm writing a program that accepts Kerberos authentication using the
> GSSAPI. The program acquires credentials using gss_acquire_cred_from() with
> a keytab specified, and this is working properly. The keytab has multiple
> principals stored in it. I want to output all the principals that were
> acquired, so I tried to use gss_inquire_cred() to find out and
> gss_display_name() to print them. This allows me to output the first
> principal in the keytab, but only the first one. Is there a way to output
> all of them? How can I iterate through all the principals acquired from a
> single keytab and output their names?

RFC 2743 is pretty clear that a GSS credential handle can represent
only a single (named) entity, though it may have credentials for
that entity with multiple mechanisms.  Since there is only one
GSS name associated with the credential; there is no need to
iterate.

That said, for the case where the kerberos keytab in question is the
default location (/etc/krb5.keytab, or what is specified by the
KRB5KTNAME environment variable), gss_accept_sec_context() with
GSS_C_NO_CREDENTIAL as the acceptor credential handle will
automatically search through all identities in the keytab and use
any of them, if they match the message from the client.

> Once I accept a security context, the program is authenticating correctly,
> so it stands to reason that I'm legitimately acquiring multiple credentials
> from the same keytab.

What you have said here is not enough information to establish your
conclusion.  How do we know what names the initiators are trying to
use to contact the service?

-Ben

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: KKDCP with KDC

[Benjamin Kaduk]

Maybe it's best to 'type kinit' to confirm that the expected binary
is what is being run...

-Ben

On Tue, Mar 07, 2017 at 10:40:36PM -0500, Greg Hudson wrote:
> I'm not sure why, but there aren't any trace logs in that output.  Trace
> log messages have timestamps and look like:
> 
> [28206] 1488944409.905935: Getting initial credentials for u...@krbtest.com

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: A request

[Benjamin Kaduk]

On Tue, Feb 28, 2017 at 06:09:44AM +, sima attar wrote:
> Hello,
> I'm student in college and I'm doing some research on Kerberos. I would love 
> to see and possibly modify the source code of its client, but I just can't 
> find it. would you please tell me where I can find the source code?
> I really appreciate your help.

Kerberos is a protocol with multiple implementations.
https://github.com/krb5/krb5 and https://github.com/heimdal/heimdal
are two such.


-Ben

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Session tickets - question

[Benjamin Kaduk]

On Wed, Feb 01, 2017 at 03:10:31PM +, Michalewicz, Brian R (CTO Technology) 
wrote:
> Good morning !!   are session tickets forwardable ?

The question could probably do with a more concrete statement.
(I assume you mean service tickets, not session tickets, which are a TLS thing.)

Taking a guess that you mean to forward a session ticket instead of a TGT,
e.g., while ssh-ing to a remote host, I believe that the protocol supports
that but that implementation support is lacking, as it's a rather unusual
thing to want to do.

-Ben

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Documenting the kerberos KDC log file format

[Benjamin Kaduk]

On Tue, Jan 31, 2017 at 12:44:20AM -0600, Benjamin Kaduk wrote:
> On Mon, Jan 30, 2017 at 11:01:46PM -0700, Todd Grayson wrote:
> > Has anyone seen a good writeup of the krb5kdc.log file output format?  For
> > the types of log file output statements that it writes out. So for example
> > the AS_REQ and TGS_REQ and follow up "closing down" lines representing a
> > full connection span.
> > 
> > More specifically does anyone have any content or pointers to constructing
> > good parsers for turning this log data into record data?  Parser tools for
> > the default MIT KDC log format?
> 
> Unfortunately, the idea of a unified format was not in mind when things
> were originally written, so a programmatic parse will be somewhat difficult.
> We've tried to be more careful with more recent additions, but feel rather
> constrained to not change the historical behavior and break existing
> log-parsing scripts.
> 
> Maybe someone else on the list has some prior art that you could start
> from, though.

I guess I should also note that if you are starting from a clean-slate,
there is a more programmatic interface available to this sort of KDC log
data via the experimental audit plugin framework
(http://k5wiki.kerberos.org/wiki/Projects/Audit) where you could write
code to have a loadable module that can log in whatever format you want.
The project is considered "experimental" in that the interface is not guaranteed
to remain stable across releases.  But maybe it is useful for your situation.

-Ben

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Documenting the kerberos KDC log file format

[Benjamin Kaduk]

On Mon, Jan 30, 2017 at 11:01:46PM -0700, Todd Grayson wrote:
> Has anyone seen a good writeup of the krb5kdc.log file output format?  For
> the types of log file output statements that it writes out. So for example
> the AS_REQ and TGS_REQ and follow up "closing down" lines representing a
> full connection span.
> 
> More specifically does anyone have any content or pointers to constructing
> good parsers for turning this log data into record data?  Parser tools for
> the default MIT KDC log format?

Unfortunately, the idea of a unified format was not in mind when things
were originally written, so a programmatic parse will be somewhat difficult.
We've tried to be more careful with more recent additions, but feel rather
constrained to not change the historical behavior and break existing
log-parsing scripts.

Maybe someone else on the list has some prior art that you could start
from, though.

-Ben

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: OTP and kadmin

[Benjamin Kaduk]

On Sun, Jan 08, 2017 at 05:02:59PM +0100, Felix Weissbeck wrote:
> Hello,
> 
> i have recently reconfigured my MIT-Kerberos setup to use PKINIT / OTP and 
> RADIUS for my admins. In my setup administrators have two accounts: one 
> "username@REALM" for regular user-stuff like mail...  and "username/
> admin@REALM" for root-logins with ssh and other administrative purposes.
> This all works just nicely and i am a huge fan.
> Users can get their tickets with a password & yubikey and then log onto the 
> servers as root.
> 
> But since i had to ''kadmin:  purgekeys -all user/admin"  in order to force 
> them to 2FA i can no longer use "kadmin -p user/admin" from a remote host.
> 
> root@ldap:~# kadmin -p fe/admin
> Authenticating as principal fe/admin with password.
> kadmin: Invalid argument while initializing kadmin interface
> 
> while my logfiles show:
> Jan  8 15:38:13 kerberos2 krb5kdc[28363]: AS_REQ x: NEEDED_PREAUTH: 
> fe/ad...@w7k.de for kadmin/ad...@w7k.de, Additional pre-authentication 
> required
> 
> I have not changed the kadm5.acl on the kdc/kadmin so they should still be 
> allowed to do this (*/admin * ) 
> 
> I guess the problem is, that the kadmin-tool does not understand how to 
> provide the preauth (just like kinit would without the otp module).
> 
> So my question is: Did i miss anything? Is there any possibility to use 
> kadmin 
> remotely with otp/2FA? Or is this not possible at the moment and users have 
> to 
> use kadmin.local?

One thing to try would be separating getting tickets and authenticating
to kadmin, aka

kinit -c FILE:/tmp/krb5cc_admin -S kadmin/admin -r5m -l5m user/admin
kadmin -c FILE:/tmp/krb5cc_admin -p user/admin

That would make it more clear if it is just a failure in the kadmin client 
logic.

-Ben

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Can I automatically cache AD tickets into a file on windows?

[Benjamin Kaduk]

On Fri, Nov 18, 2016 at 04:51:03PM +, Mauro Cazzari wrote:
> One more thing: if MIT Kerberos is installed, is there a way to populate the 
> KRB5CCNAME cache file automatically when I log on to Windows without having 
> to use a keytab or having to run a kinit under the covers?

MIT KfW does include a utility "ms2mit.exe" that attempts to export kerberos
credentials from the Windows LSA to a KfW credentials cache (which by default
will be an API: cache but can be configured to be a FILE: cache).  However,
those attempts will fail in some situations, such as when the user is a
local administrator, on recent versions of Windows.  Some sites have run
ms2mit during the login process to get that sort of behavior; however, in
the KfW 4.1 series, the LSA: support is improved and it may be feasible
to just use the LSA: cache directly.

-Ben

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: mit kdc windows client silent install

[Benjamin Kaduk]

On Fri, Nov 11, 2016 at 03:25:03AM +, Edward Gleeck wrote:
> Thanks Todd. I'll give this a shot. It'll be good from an automation
> perspective to be able to pass in parameters such as krb5.conf file and the
> cache locations, etc. But these all could be tied in to a power shell
> script so it should be good.

msiexec /quiet should work fine, yes.

Even in interactive mode there's no way to control the krb5.conf file (which
can affect default ccache locations).  There is a registry entry that can
force the path to krb5.conf (which, since the registry entry specifies the
full path, does not need to be named krb5.conf), though, FWIW.  Only
the KRB5_CONFIG environment variable has higher precedence than
{HKCU,HKLM}\Software\MIT\Kerberos5\config

-Ben


> On Thu, Nov 10, 2016 at 10:03 PM Todd Grayson  wrote:
> 
> > I've used this in the past (not with kfw tho)...  given its an MSI
> > installer this should work...
> >
> >
> > http://stackoverflow.com/questions/8560166/silent-installation-of-a-msi-package
> >
> > (assuming the kfw install package from here)
> >
> > http://web.mit.edu/kerberos/dist/#krb5-1.14
> >
> > On Thu, Nov 10, 2016 at 7:53 PM, Edward Gleeck  wrote:
> >
> > Does windows mit kdc client support silent/unattended install?
> >
> > On the release notes there are some documentation on building an installer
> > which is quite involved, so I was wondering if the currently installer
> > supports any install parameters.
> >
> > Thanks,
> > Ed
> >
> > 
> > Kerberos mailing list   Kerberos@mit.edu
> > https://mailman.mit.edu/mailman/listinfo/kerberos
> >
> >
> >
> >
> > --
> > Todd Grayson
> > Business Operations Manager
> > Customer Operations Engineering
> > Security SME
> >
> > --
> Sent from handheld device
> 
> Kerberos mailing list   Kerberos@mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Multiple radius server in an otp configuration

[Benjamin Kaduk]

On Wed, 21 Sep 2016, laurent.bas...@developpement-durable.gouv.fr wrote:

> Hello all,
>
> I use Kerberos with the OTP plugin. It works fine except i don't know
> how to put more than 1 server in the otp configuration in the 'kdc.conf' :
>
> Actually my otp section in 'kdc.conf' :
>
> [otp]
>  myotp = {
>  server = xxx.xxx.xxx.xxx:1812
>  secret = /etc/krb5kdc/mysecret
>  timeout = 3
>  retries = 2
>  strip_realm = true
>  }
>
> Is there a way to put another server in this section, like
>  server = xxx.xxx.xxx.xxx:1812 yyy.yyy.yyy.yyy:1812
> or
>  server = xxx.xxx.xxx.xxx:1812
>  server = yyy.yyy.yyy.yyy:1812
>
> I tried the 2 solutions below but it doesn't work...

A hasty read of the relevant source seems to indicate that the code is
taking the configuration entry and using it directly as the server
name+port, so your configuration would require additional development work
to be supported.

Sorry,

Ben

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: KEYRING:persistent and ssh

[Benjamin Kaduk]

On Fri, 16 Sep 2016, t Seeger wrote:

> Hello,
>
> i have a little problem with the 'KRB5CCNAME' environment variable. I set
> the default_ccache_name to KEYRING:persistent:%{uid} but if i login it is
> set to "file:/tmp/krb5cc_${uid}_XX" cause ssh sets the KRB5CCNAME
> to file:/tmp/krb5cc_${uid}_XX...
> I found a workaround with adding "unset KRB5CCNAME" to /etc/bash.bashrc but
> this is not very nice.
> Did anyone had a similar problem and found a solution?

The KRB5CCNAME environment variable takes precedence over the default
ccache name.  It sounds like you should check the system dotfiles for a
KRB5CCNAME assignment and check whether pam_krb5 is doing anything
special.

-Ben

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: GSS_S_CONTINUE_NEEDED when doing Kerberos authentication?

[Benjamin Kaduk]

On Thu, 25 Aug 2016, JSoet wrote:

> Hi, I'm implementing SPNEGO & Kerberos authentication in our application's
> webserver code and have it working fine when the KDC is Active Directory.
> I'm now testing it with an MIT KDC instance and when I attempt to
> authenticate a user who has a ticket from that KDC I get a
> GSS_S_CONTINUE_NEEDED status when I call gss_accept_sec_context...
>
> My understanding was that this couldn't happen for kerberos authentication
> though, and the GSS_S_CONTINUE_NEEDED is only for other potential
> authentication types. For example, when I was investigating other
> implementations the mod_auth_kerb module in the apache webserver and the
> kerberos module for the flask webserver both ignore the possibility of
> continuation and in the apache webserver it has this comment "This is a
> _Kerberos_ module so multiple authentication rounds aren't supported. If we
> wanted a generic GSS authentication we would have to do some magic with
> exporting context etc."

Some non-krb5 GSS mechanisms require multiple calls to
gss_accept_sec_context(); likewise if the negotiation portion of SPNEGO is
used (i.e., the client picks something that the server won't do).  But
it's hard to diagnose from just what has been said so far.  I would try
running the server with KRB5_TRACE set in the environment (a path to a log
file) and see if the trace output helps make things clear.  Otherwise,
it's probably going to be a matter of dissecting the actual protocol
messages exchanged, seeing what OIDs are sent, etc.

-Ben

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Kerberos and HTTP / HTTPS - Could Kerberos tickets be intercepted and misused?

[Benjamin Kaduk]

On Thu, 25 Aug 2016, Rick van Rein wrote:

> >>> Forwarding a TGT is bad because it is unbounded impersonation.
> >> Only when the corresponding key is supplied alongside!  [I hope I'm
> >> not taking anything out of context by saying that, I'm not sure about
> >> that but will probably be corrected if I am.]
> >
> > The TGT is all you need. It gives you access to all the resources the
> > "real owner" has access to with no limitations. You do not need the long
> > term key at all (until the TGT expires of course).
> The TGT is a Ticket, holding EncryptedData.  That encrypted portion
> must be decrypted to get hold of the EncryptionKey contained in it.
> Passing a TGT verbatim does not release this information, right?
>
> In user-to-user Kerberos, it is also possible to pass a TGT from the
> service back to the client, and the client passes that verbatim without
> being able to make heads or tails of it.  That is what I meant.  But I
> may have been nitpicking, sorry about that.

You probably are nitpicking, yes, but I think the relevant key is the
session key that is contained in the TGT -- only KDCs would have the key
to decrypt the EncryptedData of the TGT (as opposed to the enc-part of the
AS-REP which is where the client gets it).

I assume that Simo is using "TGT" to mean "TGT and session key", as would
be in a user's ccache, and not in the strict protocol data structure
sense.

-Ben

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: max_life problem

[Benjamin Kaduk]

On Mon, 1 Aug 2016, Greg Hudson wrote:

> On 08/01/2016 04:29 AM, Александр Баранин wrote:
> > I use mit kerberos, version krb5-1.14.2, compiled from source.
> > And I can't to force kdc to issue tickets for more than 10 hours.
>
> In addition to the realm setting, the client and server entries in the
> KDC database can also have a max_life value.  Using "getprinc" in
> kadmin, look at the "Maximum ticket life" on the user principal and on
> krbtgt/ALFA.IT.  Are either of them ten hours?  If so, you can change
> them with "modprinc -maxlife".

(It looks like this is on a Debian system, so I'll note that the debian
krb5-kdc package will create a kdc.conf that has max_life 10 hours on
first installation.  So, principals created when such a kdc.conf was in
place would be affected by it.)

-Ben
Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Reversing 'make install' ?

[Benjamin Kaduk]

On Mon, 25 Jul 2016, JSoet wrote:

> I had a typo in my command and so I accidentally did a normal 'make install'
> when I meant to do an install to a specific directory by specifying
> DESTDIR=/path/to/dir...
>
> It doesn't seem that there's a 'make uninstall' included, is there another
> command I'm missing that can do the uninstall?

There is no easy way to do so.  Any files that already existed in those
paths have been overwritten and cannot be recovered other than via system
backups.

Some approximations would be to look for files modified at the same time
as the installed files, or to look at those files that were installed into
the DESTDIR and locate the analogous paths in the non-DESTDIR system.

-Ben Kaduk

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: A way to automatically get a ticket through ssh for a local user

[Benjamin Kaduk]

On Thu, 14 Jul 2016, Mauro Cazzari wrote:

> I've been trying to figure out whether there is a way for a local user on
> Unix to automatically get a ticket when logging onto a server using ssh.

This terminology is sufficiently vague that I'm not entirely sure what
behavior you actually want.

By "ticket", do you mean "fresh TGT", "service ticket for
host/", or something else?

Do you expect the local user to have to enter a password when logging into
the server?

> Keep in mind that the KDC being used doesn't interface with LDAP, but it's
> rather a standalone KDC. After having added a principle to the KDC for a
> test id, I was able to log on to the ssh server and see that a ticket had
> been acquired. However, any subsequent logons to other ssh servers generate
> no tickets at all. For completeness, the first logon asks for a password,
> whereas the others don't. If I force the use of a password for the other
> logons, then a ticket gets regularly generated. Ideally, I'd like to ssh

This sounds consistent with pam_krb5 being in the stack on the server,
since it can use the supplied password to obtain a TGT for the ensuing
session.  (But is it what you want?)

> from one server to another getting a new ticket every time.
> These are the current settings I have in ssh_config:
> Host *
> GSSAPIAuthentication yes
> GSSAPIDelegateCredentials yes
> GSSAPIKeyExchange yes
> These are my settings in sshd_config:
> # Kerberos options
> KerberosAuthentication yes
> KerberosOrLocalPasswd yes
> KerberosTicketCleanup yes
> #KerberosGetAFSToken no
> #KerberosUseKuserok yes

As Brandon said, these are old/deprecated and it is unusual for them to be
the desired configuration.  But I don't know enough about what you want in
order to be able to say that for sure.

-Ben

> # GSSAPI options
> #GSSAPIAuthentication no
> GSSAPIAuthentication yes
> #GSSAPICleanupCredentials yes
> GSSAPICleanupCredentials yes
> #GSSAPIStrictAcceptorCheck yes
> GSSAPIKeyExchange yes
>
> UsePAM yes
> Is there anything else that needs to be set in order for tickets to be
> automatically generated following a ssh to a server?
> Thanks!
> 
> Kerberos mailing list   Kerberos@mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
>

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: kdb5_util fails to load propagated database under heavy load

[Benjamin Kaduk]

(This is https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=815677 , so
krb5/1.12.1+dfsg-19+deb8u2)

I had also attempted to suggest strace on irc, with the hypothesis that
the database was already locked.  (I think there have been some changes in
database locking in the intervening period, but forget the details.)

-Ben

On Tue, 23 Feb 2016, Greg Hudson wrote:

> On 02/23/2016 11:14 AM, Christopher Odenbach wrote:
> > a few days ago we upgraded our KDC server from Debian squeeze to Debian
> > jessie.
> [...]
> > kdb5_util: Resource temporarily unavailable while making newly loaded
> > database live
>
> What version of the krb5-kdc package do you have installed?  I believe
> jessie has 1.12.1, but it's useful to be sure.
>
> "Resource temporarily unavailable" is the error message for EAGAIN.  I
> can't see how krb5_db_promote() would generate that error; it doesn't do
> much besides rename a couple of files.  Can you run kpropd under strace
> and find out what system call returns EAGAIN?
> 
> Kerberos mailing list   Kerberos@mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
>

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: kprop with multiple or NATted IP address

[Benjamin Kaduk]

On Wed, 23 Dec 2015, Jerry Shipman wrote:

> I think that kpropd is trying to look up the hostname of the master in DNS, 
> and seeing the public IP, instead of the private IP which the connection is 
> coming from, and then aborting because of that mismatch (or something like 
> that).
> On a lark I tried adding the master’s hostname with its private address to 
> /etc/hosts on the slave, but it didn’t immediately seem to help.

Did you try setting rdns = false in the [libdefaults] of the krb5.conf on
both machines?  (You did not specify which version(s) of krb5 were
involved; that features is somewhat new.)

-Ben
Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: krb5 + NFS rpc.svcgssd - GSS_S_FAILURE - Wrong principal in request

[Benjamin Kaduk]

On Tue, 22 Dec 2015, 0xbabaf00l wrote:


Thank you for the large quantity of data supplied; it contains most of the
output that would usually be asked for upon a question like this.

> I ran tcpdump, but there is no communication to the kdc when rpv.svcgssd 
> starts.

It is expected for there to be no traffic between a kerberos service and
the KDC during normal operation.

> Any idea what's wrong?

Does the NFS server hostname match the created principal?  `hostname`,
`hostname -f`, and entries for 127.0.* and the hostname from /etc/hosts
are potentially interesting.

-Ben

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Windows

[Benjamin Kaduk]

On Wed, 18 Nov 2015, Randolph Morgan wrote:

> I found the answer to my question, so I thought I would share it with others
> here on the list.  To get Windows to acknowledge that a ticket has been issued

Thank you for following up!

> through MIT Kerberos KfW 4.0.1 you need to edit a registry key.  The key is
> located at: HKEY_CURRENT_USER\SOFTWARE\MIT Kerberos\Settings.  Click on Issued
> and change the value from 0 to 1.  Once I did this a klist now shows the
> ticket issued by KfW 4.0.1.

That said, I do not believe this corresponds to the behavior change you
are describing -- that registry entry controls whether the display column
for the time the given ticket was issued is present in the MIT
Kerberos.exe Ticket Manager application (and the corresponding state of
the checkbox for toggling that view column).



-Ben

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Windows

[Benjamin Kaduk]

On Mon, 16 Nov 2015, Randolph Morgan wrote:

> I have installed MIT Kerberos 4.0.1 on a Windows 10 machine. Everything
> I have read indicates that the identity manager is not integrated into
> the new ticket manager.  Ticket manager shows that I have received a

I'm not sure what you mean by these terms.  Is "the identity manager" the
"Network Identity Manager" such as is available from
https://www.secure-endpoints.com/netidmgr/v2/ ?  Is the "new ticket
manager" the "MIT Kerberos.exe" distributed in the KfW 4.0.1 installer?

> ticket from my krbtgt from my server, but Windows does not show a ticket
> when I run klist.  If I run kinit, Windows receives and the ticket

There is a klist.exe shipped with Windows by Microsoft, that is unrelated
to either of the previously mentioned programs.  (You can get the KfW
klist.exe by specifying a full path, e.g., C:\Program
Files\MIT\Kerberos\bin\klist.exe)

> manager shows a ticket, but if I go through the ticket manager Windows
> does not show a valid ticket.  is there some kind of registry setting
> that I need to modify, or is there something in my krb5.ini file that I
> should modify so that windows shows a ticket when it is issued through
> the ticket manager?

It sounds like perhaps (but it's very hard to tell since the description
lacks sufficient detail) you are putting credentials into different caches
when obtained via the command-line and via the MIT Kerberos.exe Ticket
Manager.  The KfW klist.exe with the -A argument should help clarify
whether this is the case.  Only the MSLSA: cache is accessible to the
Microsoft Kerberos implementation.

The MIT Kerberos.exe Ticket Manager does have a "make default"
functionality that will set a registry key for future credential
acquisitions.

-Ben Kaduk

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Cross-realm with AD trusting Kerberos

[Benjamin Kaduk]

On Wed, 11 Nov 2015, Leonard J. Peirce wrote:

> In an attempt to stop syncing passwords between Kerberos and AD and get to
> a single password store we are currently testing cross-realm with Active
> Directory trusting Kerberos.  We have the trust configured and our Windows
> admin here says that he can successfully authenticate against our KDC
> from an AD-enabled Windows host but is required to specify the @realm
> in order to authenticate since our AD domain is different from our
> Kerberos realm.
>
> Our Windows admin feels this is unworkable.  I'm not really a Windows/AD
> expert but looking at the Windows ksetup command the /addhosttorealmmap
> and /addrealmflags options look promising.
>
> Has anyone had success with cross-realm and AD trusting Kerberos this
> way?

I'm not entirely sure whether this is the scenario you have in mind, but
there is a registry setting to control the default realm used at login
time:
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\DefaultLogonDomain
and also
HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp\Domain
which is used for some other thing that I don't remember offhand.

At MIT, we have an AD domain WIN.MIT.EDU for the machines to be joined to,
but users authenticate to the MIT krb5 realm ATHENA.MIT.EDU.  (I was not
around at that time, but it is possible that MIT made the original request
for those settings to be added.)

-Ben Kaduk

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Incremental propagation when KDCs are clients of a different realm

[Benjamin Kaduk]

On Thu, 5 Nov 2015, Toby Blake wrote:

> To close off the thread I started...

Thanks for doing so.

> > On 2 Nov 2015, at 14:48, Toby Blake  wrote:
> >
> > Hello,
> >
> > I'm trying to set up incremental propagation on a master-slave KDC
> > configuration where the KDCs are clients of a different realm to the one 
> > they
> > serve.
> [...]
>
> I've done some hacking on this and the conclusion is that it's possible to do
> what I want, but it does require code changes.
>
> Just pointing the slave and master at an alternative krb5.conf with
> default_realm set accordingly is not enough.
>
> The changes required are in src/slave/kpropd.c:do_iprop
>
> Specifically, the iprop_svc_princstr and master_svc_princstr strings.
>
> When kadm5_init_with_skey is called, iprop_svc_princstr is set to
> "kiprop/slave.domain@DOMAIN"
>
> This comes from iprop_svc_principal - it looks like the DOMAIN part is
> generated via krb5_sname_to_principal/krb5_get_host_realm - so it's determined
> from the host name itself.
>
> master_svc_princstr is set to "kiprop/master.domain" - i.e.  no realm, so it
> must be filled in subsequently.
>
> If I set iprop_svc_princstr and master_svc_princstr to
> kiprop/host.domain@KDCDOMAIN explicitly then iprop works correctly.
>
> Hopefully the above is clear.  It's largely for my benefit to write down what
> I've discovered so I can work on a patch to do what I want properly when I
> have a bit more time.

Did you investigate putting a domain_realm mapping to KDCDOMAIN in the
alternate krb5.conf during your testing?  I would expect that to allow the
krb5_sname_to_principal behavior to be changed.

-Ben

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: end of key table reached error

[Benjamin Kaduk]

On Fri, 30 Oct 2015, Rick van Rein wrote:

> Hi Vishal,
>
> > I think there is some issue with keytab file , I see multiple kvno in
> > keytab i.e 74 & 75. Is it practical?We have 1.7 release.
>
> This is not uncommon; these are key version numbers.  They help to 
> distinguish various keys assigned to a particular principal.  RFC 4120 says

Rick skipped the important part, namely that the krb5 1.7 release is
ancient and has been out of support for years.  (I still don't think we
know of a specific bug even in that old release that would cause this
behavior, but trying a current version is probably worthwhile.)

-Ben

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Working with Microsoft Premier Support RE MIT Kerberos for Windows 4.0.1

[Benjamin Kaduk]

helpd...@mit.edu is not the correct support forum for this issue.

On Thu, 15 Oct 2015, Binder, Dale wrote:

>
> Tickets are stored in the location specified
> by environment variable

Yes, the software is doing what you tell it to do.  The "MSLSA:" cache
type corresponds to the LSA integration; KfW will only put tickets in the
LSA when told to do so, such as by setting KRB5CCNAME to MSLSA:.

-Ben

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Optimizing gss_init_sec_context possible?

[Benjamin Kaduk]

On Tue, 22 Sep 2015, Martin Gee wrote:

> Version: 1.13.2 kerb lib
> I'm using the GSS libs to impersonate a user via HTTP SPNEGO 
> (http://tools.ietf.org/html/rfc4559)
> I use gss_init_sec_context to get a Token which is sent over to the HTTP 
> service (see spec) in an HTTP Header. This is necessary. 
> I'm profiling my app. The gss_init_sec_context is the most expensive

gss_init_sec_context is permitted to (and frequently does) block on
network interaction before returning.  Would your profiling pick up such a
network delay?

> call.   I notice that gss_init_sec_context gives you a context handle. 
> Is it possible to reuse the context and still get a token? 

No.  The context handle is specific to a single ~session between client
and server (not an HTTP or TLS session, just a rough similarity).  Perhaps
RFC 7546 would help clarify how gss_init_sec_context is supposed to work.

-Ben
Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Documentation Wish List

[Benjamin Kaduk]

On Fri, 11 Sep 2015, Todd Grayson wrote:

> Anchor tags for subject items on reference pages... for example to make a
> URL like this to work to jump right to the default_tgs_enctypes
>
> http://web.mit.edu/kerberos/krb5-1.12/doc/admin/conf_files/krb5_conf.html#default_tgs_enctypes

The documentation pages are generated using the Sphinx python tool from a
ReStructuredText source, so it seems that the appropriate place to start
working on such a feature would be at http://sphinx-doc.org/index.html .
(For example, the source file for the krb5.conf manual you linked to is at
https://raw.githubusercontent.com/krb5/krb5/master/doc/admin/conf_files/krb5_conf.rst)

-Ben Kaduk

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Unable to create renewable ticket when we switched to a 1.12 KDC

[Benjamin Kaduk]

Hi Ishaan,

Russ's comments are almost certainly most relevant to your operational
situation, but for completeness, a couple more answers inline.

On Fri, 21 Aug 2015, Ishaan Joshi wrote:

Thanks a bunch for the quick responses. Let me restate the problem we
 faced ( which is exactly what Ben described):

 Our earlier behaviour was to issue the following kinit to periodically
 renew our daemon's ticket: kinit -r time_string -k -t keytab
 service_name. The time_string was hard coded to a day. The renewal time
 was controlled by another option that was passed in.

 When we first ran against a 1.12 KDC, the ticket became non renewable
 because the hard coded value for time_string happened to be equal to the
 ticket_lifetime in the krb5.conf.

I have a few follow on questions:

- Can I assume that our previous behaviour was incorrect, and we just
got lucky because it was not enforced.

This is a little bit of a grey area in the specification; there's no need
for the issued ticket to be renewable if the renewable lifetime is less
than or equal to the issued lifetime, and whether the KDC chooses to set
the flag is largely an implementation choice.

- Do we need to use the -r flag, given that the ticket is renewed
periodically.

In this situation, no; using the -r flag is only relevant if you want to
later utilize kinit -R to actually renew the ticket.

- Are there any risks to passing in a value via -l on older KDCs, apart
from overriding the value in the krb5.conf.

No.

-Ben

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Unable to create renewable ticket when we switched to a 1.12 KDC

[Benjamin Kaduk]

On Thu, 20 Aug 2015, Ishaan Joshi wrote:

 Hi,

   We recently ran into a problem wherein the tickets for out service could
 not be renewed. After a lot of digging, we traced the change in behaviour

Can you say more about the problematic behavior you were experiencing?  My
understanding is that the commit you link to was not expected to result in
any noticable decrease in functionality, so it would be helpful to
understand what actually happened.

-Ben Kaduk

 to
 https://github.com/krb5/krb5/commit/4f551a7ec126c52ee1f8fea4c3954015b70987bd,
 which subtly changes the behaviour of renewable ticket handling. It would
 really help (and much appreciated) if it were possible to document the
 change in behaviour, maybe an addendum to release notes?

 Thanks !

 Ishaan
 
 Kerberos mailing list   Kerberos@mit.edu
 https://mailman.mit.edu/mailman/listinfo/kerberos


Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Compatibilty between mixed kerberos release (KDC 1.12 client 1.10).

[Benjamin Kaduk]

On Wed, 29 Jul 2015, Ken Hornstein wrote:

 Is there any general wisdom out there about mixed KDC/Client versions?  Are
 there concerns around allowing environments drift to where a KDC would be
 on a later release than the clients?

 FWIW, we run a whole bunch of crazy versions of Kerberos, and generally
 there is not an interoperability problem; the protocol is pretty well
 specified and in general everything works fine at that level.

Yes; it is expected that any implementation of the kerberos protocol can
successfully talk to a peer running a different implementation, including
the case where the peers differ only by software version and have a common
lineage.

 There seems to be a change in default behavior in the 1.12+ where renewable
 tickets must be specifically requested (RHEL 7 is including the 1.12 as the
 tested krb release in platform).

 This is more of a problem, but I don't consider this an interoperability
 issue.

That sort-of calls to mind
https://github.com/krb5/krb5/commit/4f551a7ec126c52ee1f8fea4c3954015b70987bd,
and makes me wonder what the actual lifetimes in the request are (and the
max permitted by the KDC).

-Ben

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Compiling on Solaris8

[Benjamin Kaduk]

There are automated nightly builds on solaris 9, so it has a good chance
of working.  Try it and report back!

-Ben Kaduk

On Wed, 1 Jul 2015, Arewe There wrote:

 Hello,

 I'm trying to compile the latest release 1.13 on a Solaris 8 x86 box using
 gcc 4.2. Has anyone tried it? Is it even possible? Same question for a
 Solaris 8 sparc box.

 Thanks.
 
 Kerberos mailing list   Kerberos@mit.edu
 https://mailman.mit.edu/mailman/listinfo/kerberos


Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Kerberos SNC Shim and OSX Yosemite

[Benjamin Kaduk]

On Wed, 1 Jul 2015, Jeffery Dowell wrote:

 Hello Everyone,

 I have a question for the community regarding the Kerberos SNC shim. I am 
 currently trying to get authentication to SAP through Kerberos working on OSX 
 10.10 (Yosemite). In Yosemite, Apple has removed support for DES, which means 
 that I can't get a Kerberos ticket from Kerberos systems still using DES. As 
 workaround, I am using a heimdal implementation to request a ticket and have 
 it appear in the Mac ticket viewer. However, when I open SAP I get the error:
 GSS-API(min):Encryption type des-cbc-md4-deprecated not supported
 I am using the Shim SNC adapter from Ben on GitHub to fix the 32/64 bit
 java issue that was found a while back. It appears that SAP interfaces
 with this adapter but that the adapter doesn't see my ticket. The ticket
 does appear in the OSX ticket viewer and seems usable to the rest of the
 system.

I am curious what you mean by seems usable to the rest of the system --
my understanding was that Yosemite had completely removed support for
using single-DES enctypes.  That is, you may be able to list it, but I
would be surprised if you could actually do anything else with it.

Apple is well-justified in the removal; single-DES is deprecated for use
in Kerberos (RFC 6649) and provides only negligible security (keys can be
brute-forced in under a day for around $50).  My personal advice would be
to take this as a strong signal to update the Kerberos infrastructure away
from single-DES.

 Should I insert my heimdal ticket in a different manner?
 Is there a heimdal equivalent for the MIT shim?
 Perhaps there is an all MIT Kerberos option for sidestepping the Apple
 implementation?

That said, the SNC shim should work just fine if linked against a
different kerberos implementation, such as the heimdal you are using to
acquire the single-DES ticket in the above scenario.  Instead of using
-framework GSS to link it, use the normal -L/path/to/heimdal/lib -lgssapi,
and you will also need to change the include statement in sncgss.c from
GSS/gssapi.h to the corresponding include for heimdal (gssapi.h or
gssapi/gssapi.h), and add -I/path/to/heimdal/include on the compiler
command line.

-Ben

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

kfw-4.1-beta2 is available

[Benjamin Kaduk]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

MIT Kerberos for Windows 4.1-beta2 is now available for download from

 http://web.mit.edu/kerberos/dist/testing.html

The main MIT Kerberos web page is

 http://web.mit.edu/kerberos/

Please send comments to the krbdev list.

Major changes in 4.1
=
These changes may also be found at

http://web.mit.edu/kerberos/kfw-4.1/kfw-4.1.html

Developer experience:

* KfW now uses the UI compiler uicc.exe, to support the transition from the MFC
ribbon to a native Windows ribbon. The uicc.exe found in Visual Studio 2010
is insufficient; Service Pack 1 is required.

Administrator experience:

* The default realm for KfW can be set in the registry; this setting takes
precedence over the default realm set in krb5.ini.

End-user experience:

* The support for the MSLSA: cache type has been greatly improved, making
better use of the native LSA operations. This should improve the user
experience at elevated UAC levels.

* The Ribbon interface has been switched from the MFC to the native
implementation, improving accessibility for screen-reading software.

* Registry entries are set for the KdcNames of certain Kerberos realms; such
entries are needed for the LSA to retrieve tickets from non-AD realms.

* A message is displayed on successful password change.

* Updates from the 1.11, 1.12, and 1.13 krb5 release notes are also applicable
here.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (FreeBSD)

iQGgBAEBCgAGBQJVjFlbAAoJECjZpvNk63USziQMHAwEFgVhSE4X9rGKonzM31PM
ZpP3zzyP9HOD4ekuOd1F0g5WxKVTzLUYhK8ONpD83u3xmVcJBZiTDlvFCXt5OgUX
BEIsl5siGQVVqx6bcoJTzFGEF0SETOfCGdM0WUx8+aY7ibe5nymqiRvmc+8Iv1AL
Pnkn83sZ8tmd8qeevADhqRB9Mkd7lanO++NK8xUFawQxoofZJrghar9n2YKwHiX+
WwuqxC/6i0UOaPliU5RtwVLbdLzjTgvaiZAIOlTN5hh/mgQ1Kv8YMgK5ZLeDc35S
VDdsP6zas5Cl/9O2AF9PzWelzXNU2tS7DqUuq0D152Wu6XdycKans9pXxIFG5QrO
2uHvFB8RrXMicKhNq13pG/YW7ugB05xlK4IiU/hQoAtyWB2qBmyrJldQLmKGrXCL
TfLk7uPDbmoCnPGXDFE2rYnithD9CPxaKZs+7apQtH+uZjqCoTXOZwYgDui96J13
CjXjFO20SEZEMSHnKoGesvSrpAibvz03MAy8sET/eQPe41g=
=hROm
-END PGP SIGNATURE-

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Kerberos Authentication question(s)

[Benjamin Kaduk]

Just a couple additions and corrections (inline).

On Wed, 24 Jun 2015, Michael B Allen wrote:

 On Wed, Jun 24, 2015 at 2:07 PM, Albert C. Baker III alb...@voltage.com 
 wrote:
  I am using the Java class org.apache.hadoop.security.
  authentication.server.AuthenticationFilter from Apache
  Hadoop 2.5.0 as a filter in front of a Tomcat 6 Servlet we
  wish to add Kerberos authentication to.

Michael has basically made this point at the end of his message, but just
to drive it home: the HTTP Negotiate authentication you are using is the
SPNEGO mechanism for the GSS-API protocol.  Since the GSS-API is the
Generic Security Service Application Programming Interface (emphasis on
Generic), it supports using security mechanisms other than Kerberos, even
though Kerberos is what you want to use with it (and what most people use
with it).  Your goal (described below) of constructing a token by hand
using the server's private key is inherently plowing through several
layers of abstraction, and because the GSS-API is generic, not specific to
Kerberos, there are not interfaces which facilitate such abstraction
violations.

 gotten better over the years). Note that the reason the Windows SSPI
 is used by Java is largely because there is otherwise no way to insert
 credentials into the Windows credential cache. It actually used to be
 possible but at some point early on MS decided this was probably not a
 good idea and so now Java and MIT or Heimdal or whoever cannot insert
 creds into the Windows credential cache. They have to just use the

This is simply not true -- both MIT KfW and Heimdal for Windows can insert
Kerberos credentials into the Windows LSA credential cache.

SomeTokenType token = new SomeTokenType();
code to set token parameters
 
// my understanding of Kerberos is that the only cyphertext key
// needed on this token
// is one of the server principal's keys from the Keytab file
// (which does contain ~5
// keys of different sizes and types, I've checked)
EncryptedTokenType etoken = encrypt token with a key from keys
byte[] array = etoken.getBytes();

 First, note that the token in the Authorization / WWW-Authenticate
 headers in HTTP are not quite the same as the token as defined in
 the Kerberos protocol documentation. Technically, the HTTP token is
 the Base64 encoded product of the InitializeSecurityContext function
 of the Microsoft Windows SSPI of which there are several but could be
 Kerberos or NTLM but in practice almost always SPNEGO which is a
 little binary wrapper used to NEGOtiate Keberos or NTLMSSP where
 NTLMSSP is a little binary wrapper around NTLM.

Yes (though I don't think that the output of InitializeSecurityContext is
the normative reference in the RFCs -- it's wire-compatible with the
corresponding GSS-API tokens, which are used in the SPNEGO and
HTTP-Negotiate specs).

 Lost yet? Anyway, with
 respect to Windows HTTP clients (including Firefox and Chrome running
 on Windows which just tap into the Windows SSPI), the HTTP token is
 almost certainly an SPNEGO token. However, if you're just trying to
 initiate authentication (meaning you're the client), you can
 *probably* skip SPNEGO and feed the server a raw Kerberos token. At

Right -- this token is passed as input to gss_accept_sec_context() (or the
Windows equivalent), and the acceptor is willing to handle whatever
mechanisms the implementation supports, which will include both SPNEGO and
Kerberos, here.  (It is possible for the acceptor to construct a
credential that is limited to only certain mechanisms, but I believe this
to be rare.)

 least Windows servers like IIS should detect this and handle it
 correctly. And Apache's mod_auth_kerb would almost certainly handle it
 correctly as well.

  So, questions here:
1) What is the Java Class that embodies the Kerberos Auth Token sent
   in Authorization Negotiate?

 Again I am not familiar with your token code but fortunately, even
 though the Authorization: Negotiate ... token is an Internet
 Explorer-ism, it's SPNEGO payload is largely compatible with the

Huh?  HTTP-Negotiate is published as RFC 4559 and is supported by all
major browsers.  The token formats described therein are explicitly the
SPNEGO GSS-API token formats; there's no need to hedge with largely.

 Kerberos token and more generally the GSSAPI token where GSSAPI is the
 RFC definition of this type of authentication which is meaningful
 because JGSS is the Java implementation of this and this is a run-on
 sentence.

 So with respect to actually coding a Java HTTP client to do Kerberos,
 something would ultimately need to call GSSManager.createContext with
 the Kerberos OID and then GSSContext.initSecContext and then the
 result of looping over that consumes and emits a token (which
 *should* then be wrapped in the SPNEGO business) and Base64 encoded /
 decoded. Maybe the Hadoop library is doing that for you. I'm not
 familiar with it. Personally I would be very 

Re: pkinit makes application crash

[Benjamin Kaduk]

On Wed, 24 Jun 2015, Osipov, Michael wrote:

 Hi folks,

 we are trying to perform some LDAP requests with Perl against Active Directory
 with Kerberos auth by MIT Kerberos.
 A core file is dumped and following written to stderr:
 $ ./ldap.pl
 Assertion failed: __thread_init == NULL, file 
 ../../../../../core/libs/libc/shared_em_32_perf/../core/threads/pthread_stubs1.c,
  line 1045
 Abbruchkommando (Speicherabzug geschrieben)

 I first have assumed that the Perl module is broken but I guess it isn't?!
 Loading the core file into GDB gives me:
 ===
 (gdb) where
 #0  0x6000c020f6d0:0 in _lwp_kill+0x30 ()
from /usr/lib/hpux32/libpthread.so.1
 #1  0x6000c0174be0:0 in pthread_kill+0x9f0 ()
from /usr/lib/hpux32/libpthread.so.1
 #2  0x6000c0403460:0 in raise+0xe0 () from /usr/lib/hpux32/libc.so.1
 #3  0x6000c05277b0:0 in abort+0x170 () from /usr/lib/hpux32/libc.so.1
 #4  0x6000c03ce5f0:0 in _assert+0x260 () from /usr/lib/hpux32/libc.so.1
 #5  0x6000c0590980:0 in pthread_once+0x80 () from 
 /usr/lib/hpux32/libc.so.1
 #6  0x6000c4bab160:0 in pkinit_init_plg_crypto ()
 at pkinit_crypto_openssl.c:410

This pthread_once() stuff is in the library initializor for pkinit's use
of openssl, thought it's not immediately clear what assertion is being
made in the innards of libc.  The fact that the file named in the
assertion failure message is named pthread_stubs1.c makes me wonder if
there is an issue with an executable which was not compiled as threaded
(i.e., is compiled to use the stub implementation) then loaded an object
which uses the pthread interfaces, but that is basically pure speculation.
I don't have enough experience with HP-UX to have any sense of how
plausible that might be.

 What we would like to do:
 Use Net::LDAP with uses Authen::SASL which in turn calls Authen::SASL::XS with
 a Perl to C binding against Cyrus SASL. The very same happens when 
 Authen::SASL::Perl
 with GSSAPI module is used: failure. This must be some generic incompat.
 All calls are performed with an empty ticket cache (non-default location as 
 once
 advised by Greg Hudson) and a client keytab.
 Using an interactive ticket cache makes the entire stuff work, so client 
 ticket
 makes it crash. We do not use PKINIT at all.
 Interesting to say that the very same LDAP request works with ldapsearch(1)
 and a minimal C app with libldap.

 Any ideas? Can this be some interference with Perl and preinit of OpenSSL?

Not necessarily perl itself, but this is quite plausible.  The motivation
for switching to library initializers for the openssl calls is discussed
in http://krbdev.mit.edu/rt/Ticket/Display.html?id=6413 , but in general,
openssl is not amenable to having multiple library consumers in a given
application.

I was not directly involved in this work, so it is possible that someone
else (Greg?) may have more insights to offer.

 As a workaround, I would recompile MIT Kerberos on all servers without pkinit
 for now.

That workaround seems advisable for now.

-Ben Kaduk

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Possible Windows Build Bug

[Benjamin Kaduk]

On Mon, 22 Jun 2015, Zachary Greve wrote:

 In the echo_files method in the libecho utility there is a line that reads:

 ff = _findfirst(f, fdt); // line 64

 which errors out with an access violation in ntdll.dll.

Can you say a bit more about where this crash is observed?  E.g., during a
build of what version of the krb5 tree (where in the build?), using which
compiler and windows SDK version, etc..

 Changing the line to read:

 ff = _findfirst(filepath, fdt);

 fixed the issue.

 Is this a bug?

This piece of code is (very old and) written in a rather strange way, but
I am not convinced that your propsal is a correct fix to the bug, if one
is present.

The purpose of this utility is to expand wildcards in a given path
expression (it is only used in two makefiles in the tree).  There seems to
be an implicit assumption that the wildcard will only occur in the last
path component.  The _find() family returns only the matched filename
(without directory), so libecho requires a copy of the containing
directory as well as the full path (i.e., wildcard expression) in order to
fulfil its purpose of printing out all matches to the wildcard.  The
directory is stored in the 'filepath' variable, whereas the wildcard
expression is in 'f'.  So, I think the _findfirst() call should use f, not
filepath.

I think we need to hear more about the crash and the context of the failed
call in order to say what's going on here.

-Ben Kaduk

P.S. kfwdev@ might be a better list to discuss this on.


Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Does this separate thread connection need another as_req/rep pair?

[Benjamin Kaduk]

On Sat, 13 Jun 2015, Chris Hecker wrote:


 Finally getting to this...

  You might be able to make a new context and use
  krb5_auth_con_getsendsubkey(), krb5_auth_con_recvsubkey(),
  krb5_auth_con_setsendsubkey(), and krb5_auth_con_setrecvsubkey() to
  copy the keys. I don't think rd_priv and mk_priv use anything else in
  this configuration.

 I think I want the _k versions of the set functions, no?  It looks like
 the gets malloc a block, so the sets can just set and ref it, right?
 Hmm, no, it looks like create_key also copies the data.  Is there any
 way to not do the wasted extra malloc?  It looks like krb5_key_st is
 opaque, so I can't ref it and then use that to copy the keyblock even.

 On May 8, 2015 8:41 AM, Greg Hudson ghudson at mit.edu wrote:
% (Don't use the _k variants; they use reference counts rather than
% copying, and krb5_keys are mutable and not internally locked..)


 In other words, I want to get the keyblocks with the current API, but
 then set the pointers without another call to krb5int_c_copy_keyblock.
 I guess I could make a couple new APIs since this is all linked
 statically in my app...

See above.

-Ben

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Does this separate thread connection need another as_req/rep pair?

[Benjamin Kaduk]

On Sat, 20 Jun 2015, Chris Hecker wrote:

 I think was unclear.  I don't think there's a way to avoid a wasted
 allocation here.  I'm happy to have separate keys per thread, but there are
 three keyblocks allocated in this scenario:  there's the original, get
 allocates a copy, set allocates a copy, then I have to free the one from
 get because it's not used.  There should be a version of set that takes
 ownership of the memory, I think.  Make sense?

I do now understand what you were saying in a way that I did not before;
thanks for the clarification.

That said, I don't think that API should exist outside your personal fork,
since it's only useful in specific cases and complicates the memory
ownership story.

-Ben

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Issue with kvno

[Benjamin Kaduk]

On Fri, 29 May 2015, vishal wrote:

 My question is that why kvno is not always present in ticket and this
 ticket is basically which comes in TGS-RESP(from home domain) and sname is
 krbtgt for trusted domain in TGS-REQ.

 I see kvno only when new trust is created between domain and we join to
 domain. So under what situation kvno would be there in ticket?

 I hope it is clear.

I guess it's clear enough, for the answer we don't know.

The kvno field in the ASN.1 EncryptedData type is an optional field, used
to assist the recipient in selecting which key to use to decrypt the data.
Given that the Microsoft KDC is generating this EncryptedData, we probably
would only know when it includes the kvno by examining its source code,
which is unavailable.

-Ben

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Issue with kvno

[Benjamin Kaduk]

On Fri, 29 May 2015, vishal wrote:

 can someone please reply to this as well just for my understaning:

 why do i see kvno in ticket only when i create new trust and join
 domain..after 1-2 hour of trust creation I do not see kvno in ticket.

I don't think there's sufficient detail there for me to understand the
situation you are asking about.

-Ben

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Migrating Krb5 realm

[Benjamin Kaduk]

On Thu, 21 May 2015, Andreas Ladanyi wrote:

 Hi,

 i want to migrate my old Krb5 Realm. I have a Krb5 own DB and want to
 use LDAP to hold the principals in the future. Also i want to change the
 realm name.

 I read a lot about dumping the Krb5 DB with kdb5_util and restore them.
 I also read something about replacing the master key or to reencrypt the
 Krb5 DB with a new master key when dumping the DB with kdb5_util.

 I dont read something about changing the realm name in the dumping
 process. So iam asking myself the question if it is possible to dump,
 reencrypt and change the realm name without changing the principals
 password hashes ?

The realm name is part of the salt used as input to the password hashing
process.  Normally, the salt is not stored in the database and the default
salt is computed at runtime by concatenating the realm and principal name.
Changing the realm without changing the password-derived keys will require
manually setting an explicit salt on all password-derived keys.  Renaming
a realm is not a common operation, so good tooling has not been developed
and incorporated into the release.

-Ben Kaduk

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

RE: gssapi32.dll

[Benjamin Kaduk]

Hi Jeffery,

On Fri, 8 May 2015, Jeffery Dowell wrote:


 Just to close the loop on this one. We found that the conflicting DLL
 (Krb5_32.dl) was put into C:\windows\sysWOW64 by a Library program
 called ALEPH. Apparently it is a somewhat commonly used Library system
 so this knowledge might help others who run into similar issues.

Thank you for tracking it down and reporting back; it's great to have a
full understanding of what's going on.

-Ben

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

RE: gssapi32.dll

[Benjamin Kaduk]

On Tue, 21 Apr 2015, Jeffery Dowell wrote:

 Thanks Ben, This is most helpful and I am trying multiple variations on
 my test systems. I haven't had any luck as of yet on a fix. I just
 joined the list yesterday and missed out on the prior conversation about
 this topic. I don't see a way to access list archives so if anyone has
 access to this prior topic and can forward, it would be most
 appreciated. The subject of concern is:

The list is archived at http://mailman.mit.edu/pipermail/kerberos/ ,
though the web view is not very searchable.  (Downloading the full raw
archive will get something that a local MUA should be able to search,
though.)

 SncPDLINIT()==SNCERR_INIT
  Unable to load GSS-API DLL
 Error 182 = The operating system cannot run C:\Program Files
 (x86)\MIT\Kerberos\bin\gssapi32.dll
  Return Code -1
 System Call LoadLibrary

I did a bit of poking with dumpbin.exe /dependents on my local machine,
but nothing is standing out as obviously a candidate for being missing,
other than the C runtime.  My build is a debug build, so I have
msvcr100d.dll, but you probably have a non-debug build.

Can you try using Dependency Walker (http://www.dependencywalker.com/) to
see if there are missing dependencies which could explain the LoadLibrary
failure?

-Ben

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: gssapi32.dll

[Benjamin Kaduk]

On Tue, 21 Apr 2015, Meike Stone wrote:

 Hello Jeffery,

 2015-04-20 19:38 GMT+02:00 Jeffery Dowell jeffery.dow...@duke.edu:
  Hello,
 
  I am currently deploying the MIT Kerberos for Windows 4.01 client (32bit) 
  for use in our Kerberos environment. Specifically, The Kerberos client is 
  used to provide credentials to SAP software. While the installation is 
  going well on many computers, I am having a reoccurring, currently 
  unsolvable, problem on several. Reboots nor reinstalls help the issue. The 
  error has occurred on both 32 bit and 64 bit versions of Windows 7. The 
  install of MIT Kerberos goes through without error. It seems to be the 
  availability of the gssapi32 module specifically that causes the issue. I 
  am attaching a screenshot of the issue. Has anyone encountered this error 
  before?


 At the moment, we try the same, working on a SSO for Workstations
 (Wndows 7) that are not member in the AD domain!
 We got the MIT-Kerberos Client running on Windows 7.
 So what client OS and gssapi32.dll do you use?

 For SAP you need a special gssapi32.dll from SAP, not that from the
 MIT Kerberos client!

That is not correct.  The SAP SNC layer is quite flexible, and can cope
with an external gssapi32.dll directly (such as the one in KfW), as well
as a few other libraries.

-Ben

 You need  a SAP account to download
 https://websmp230.sap-ag.de/sap%28bD1lbiZjPTAwMQ==%29/bc/bsp/spn/sapnotes/index2.htm?numm=352295
 or maybe look here:
 http://solveissue.com/note?id=352295
 (no warranty if virus free!)

 Maybe it helps

 Meike

 
 Kerberos mailing list   Kerberos@mit.edu
 https://mailman.mit.edu/mailman/listinfo/kerberos


Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: MIT Kerberos Client and MSLSA Cache

[Benjamin Kaduk]

On Tue, 21 Apr 2015, Meike Stone wrote:

 2015-04-20 21:29 GMT+02:00 Benjamin Kaduk ka...@mit.edu:
  On Mon, 20 Apr 2015, Meike Stone wrote:
 
  Hello Benjamin,
 
  2015-04-17 22:18 GMT+02:00 Benjamin Kaduk ka...@mit.edu:
 
  
   However, with the currently released versions, if you have UAC enabled,
   the non-SSPI clients will not work.  If you do not have UAC enabled, they
   will not work very well (they will wait for some DNS timeouts) unless you
   set
   HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Domains\REALM.NAME\KdcNames
   to a multi-string entry with the DNS names of the KDCs for the realm's
   KDCs.
 
  I've seen this before, that's what Microsoft does if ksetup.exe is invoked!
  But on a test PC, I dropped that configuration and it works as well,
  no (appreciable) timeout seen, but I haven't sniffed.
  I'll digging deeper soon!
 
  Ah, I failed to say that this is only needed if the realm in use is not an
  AD realm.  The LSA will use AD-specific DNS queries to locate KDCs in AD
  realms, but will not use the standard SRV lookups to locate KDCs for Unix
  realms.

 Ah, ok ... if configured in registry, it will use that values, else it
 will try DNS SRV lookup ...

 All clients here that will use the MIT-Kerberos client are belonging
 an other department, not administrated by us.
 So maybe it is wise to configure the KDC and default realm in the registry!

It sounds like configuring the KDC entries would be reasonable.  There's
not really a default realm setting in the registry, though.

  But one question. I tried the same on Windows 2003, But it didn't work.
  We have a few stand alone Terminal servers, managed from other
  departments (same with the Windows 7 PC's)
  Is it possible to do that with Windows 2003 too - would be very nice!
 
  I don't remember anything offhand that would prevent SNC_LIB=gssapi32.dll
  from working on Windows Server 2003.  The code first tries to use some
  modern API calls which are not provided on systems that old, but should
  have fallbacks to older APIs which should be present there.

 It does not work at the moment...
 Look at the following commands, invoked on the (test-) Windows2003:
 =
 # get a TGT for the default cache:
 C:\Programme\MIT\Kerberos\binkinit -c API: mst...@corp.org
 Password for mst...@corp.org:

 # show the TGT
 C:\Programme\MIT\Kerberos\binklist
 Ticket cache: API:Initial default ccache
 Default principal: mst...@corp.org

 Valid starting ExpiresService principal
 04/21/15 15:29:15  04/22/15 01:29:19  krbtgt/corp@corp.org
 renew until 04/22/15 15:29:15

 # Every thing is working as expected with default (MIT) ccache!
 # show the MSLSA cache:
 C:\Programme\MIT\Kerberos\binklist -c MSLSA:
 klist: Matching credential not found while retrieving principal name

This is one of the bugs I fixed on master -- the routine to get the
principal name from the cache attempts to get the full TGT, which is
(frequently, in most configurations) denied by security policy.  My new
code will just request a list of the tickets present (and not the secret
keys), which should always succeed and be able to determine the principal
name.

There are some related codepaths that fail if there is only a TGT in the
cache, but would succeed if there was a service ticket present (since the
session key can be retrieved for a service ticket), but I don't think this
is actually relevant in this particular case.

 # now I try to copy the TGT in the MSLSA cache
 C:\Programme\MIT\Kerberos\binmit2ms.exe
 mit2ms.exe: Ccache function not supported: read-only ccache type while
 copying default MIT ccache to MSLSA ccache

 # MSLSA ccache is readonly?
 # this procedure works for me on Windows 7

This is going through a different (open-coded) version of the
principal-detection logic, so it is unsurprising that it fails.

The KRB5_CC_READONLY error is only generated in a small number of places,
though it's not 100% clear which one would be at fault.  krb5_lcc_store()
would make the most sense, since we first try the KerbSubmitTicketMessage,
which is not supported on XP and Server 2003.  Since that works on all
newer systems, the fallback codepath is poorly tested.  The fallback goes
through the KerbRetrieveEncodedTicketMessage, which IIRC will fail if the
target realm is a non-AD realm and there are no registry settings for the
KdcNames.

 Now I try the get the TGT direct in the MSLSA ccache:
 =
 # destroy Initial default ccache
 C:\Programme\MIT\Kerberos\binkdestroy

 # get TGT for MSLSA ccache (works on Windows 7), no error shown
 C:\Programme\MIT\Kerberos\binkinit -c MSLSA: mst...@corp.org
 Password for mst...@corp.org:

 # show the TGT, nothing shown ...
 C:\Programme\MIT\Kerberos\binklist -c MSLSA:
 klist: Matching credential not found while retrieving principal name

 # try default ccache, same result, nothing shown ...
 C

Re: gssapi32.dll

[Benjamin Kaduk]

On Mon, 20 Apr 2015, Jeffery Dowell wrote:

 Hello,

 I am currently deploying the MIT Kerberos for Windows 4.01 client
 (32bit) for use in our Kerberos environment. Specifically, The Kerberos
 client is used to provide credentials to SAP software. While the
 installation is going well on many computers, I am having a reoccurring,
 currently unsolvable, problem on several. Reboots nor reinstalls help
 the issue. The error has occurred on both 32 bit and 64 bit versions of
 Windows 7. The install of MIT Kerberos goes through without error. It
 seems to be the availability of the gssapi32 module specifically that
 causes the issue. I am attaching a screenshot of the issue. Has anyone
 encountered this error before?


 Thanks for any assistance you can provide.


 Here are a few highlights from the attached screenshot:

 SncPDLINIT()==SNCERR_INIT
 Unable to load GSS-API DLL
 Error 182 = The operating system cannot run C:\Program Files 
 (x86)\MIT\Kerberos\bin\gssapi32.dll
 Return Code -1
 System Call LoadLibrary

It seems that gssapi32.dll has some library dependencies which are not
included by the installer.  If there are other applications installed on
the system which also need those support libraries, the needed libraries
will be present and consumers of gssapi32.dll will work fine.  If not,
then the errors such as this become visible.

I do not have the old mail from when this issue was previously raised
right at hand, but it looks like at least msvcr71.dll is likely to be
missing, and potentially other such support libraries as well.  You should
probably investigate the Microsoft Visual C++ 2010 Redistributable Package
(e.g., https://www.microsoft.com/en-us/download/details.aspx?id=) and
see if that can provide the needed libraries.

-Ben Kaduk

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: MIT Kerberos Client and MSLSA Cache

[Benjamin Kaduk]

On Mon, 20 Apr 2015, Meike Stone wrote:

 Hello Benjamin,

 2015-04-17 22:18 GMT+02:00 Benjamin Kaduk ka...@mit.edu:

 
  However, with the currently released versions, if you have UAC enabled,
  the non-SSPI clients will not work.  If you do not have UAC enabled, they
  will not work very well (they will wait for some DNS timeouts) unless you
  set
  HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Domains\REALM.NAME\KdcNames
  to a multi-string entry with the DNS names of the KDCs for the realm's
  KDCs.

 I've seen this before, that's what Microsoft does if ksetup.exe is invoked!
 But on a test PC, I dropped that configuration and it works as well,
 no (appreciable) timeout seen, but I haven't sniffed.
 I'll digging deeper soon!

Ah, I failed to say that this is only needed if the realm in use is not an
AD realm.  The LSA will use AD-specific DNS queries to locate KDCs in AD
realms, but will not use the standard SRV lookups to locate KDCs for Unix
realms.

Furthermore, the timeout behavior is subject to some caching, IIRC.  The
full situation is difficult to characterize externally.

  There are several improvements on master that have not made it into a
  release yet; I hope to put out a KfW 4.1 release in the next couple of
  months which includes them.

 What improvements?

It boils down to using the proper interfaces to have the LSA get service
tickets, instead of retrieving the TGT and doing it ourself.  Also some
changes to not try to get the TGT when it is not needed.

  Using ksetup and logon to the kerberos real works, but I don't can
  make that deep changes on the  Windows workstations (e.g. ne
  userprofile, etc ).
 
  I'm not sure I understand this paragraph.

 I mean the using of Microsofts Kerberos Client (W7 included / W2k3 in
 support tools),
 configured by ksetup.exe - Installation without MIT-Kerberos Client!
 That solution is working as well, but the user must logon to the
 Kerberos domain and
 the user gets a new profile! Microsofts kinit is only invoked during
 the logon process.

I believe that is correct, that using only the Microsoft tools it is only
possible to convert a password into a Kerberos TGT at logon time.

  Main cause it to get running the SAP-GUI, using Kerberos to authenticate!
  Mayby someone has an idea to get this running on a simple workstation
  without domain or Kerberos membership.
 
  I am surprised that it is not working; maybe the version of SAP GUI that
  MIT distributes internally has some custom config in place.  In any case,
  you should be able to set SNC_LIB to point to the gssapi32.dll library and
  avoid the MSLSA: cache.

 Yes, now It works - Thanks!

I'm glad that you have things working (in two different ways, if I
understand correctly?).

 But one question. I tried the same on Windows 2003, But it didn't work.
 We have a few stand alone Terminal servers, managed from other
 departments (same with the Windows 7 PC's)
 Is it possible to do that with Windows 2003 too - would be very nice!

I don't remember anything offhand that would prevent SNC_LIB=gssapi32.dll
from working on Windows Server 2003.  The code first tries to use some
modern API calls which are not provided on systems that old, but should
have fallbacks to older APIs which should be present there.

I do note that Windows Server 2003 goes out of support in just a few
months, so hopefully those machines will not be in service for much longer
anyway.

-Ben

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: MIT Kerberos Client and MSLSA Cache

[Benjamin Kaduk]

On Fri, 17 Apr 2015, Meike Stone wrote:

 Hello dear list,

 I have Windows 7 workstations, not joined to a AD Domain.
 I like to use MIT Kerberos client to authenticate to a Kerberos server
 and run several programs using Kerberos to authenticate.
 The MIT client is installed and running, I get a krbtgt and if I use
 Firefox with network.auth.use-sspi=false, Firefox uses Kerberos as
 well.

 But my problem are applications that using only the MSLSA Kerberos
 cache (for example SAP-GUI via gsskrb5.dll) (SSPI)

SAP-GUI will use gssapi32.dll just fine, for what it's worth (we use it
that way at MIT).

 Is is possible, to configure the MIT-Kerberos client to use this cache (too)?

It is possible to configure MIT Kerberos to use that cache, though it is
not very well exposed in the GUI at the moment.  You can set
HKCU\Software\MIT\Kerberos5\ccname to MSLSA: in the registry to make it
the default, or explicitly run kinit.exe -c MSLSA: principal from
cmd.exe to just get a ticket.  (Once you have a ticket, the make default
button will set the registry entry for you.)

However, with the currently released versions, if you have UAC enabled,
the non-SSPI clients will not work.  If you do not have UAC enabled, they
will not work very well (they will wait for some DNS timeouts) unless you
set
HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Domains\REALM.NAME\KdcNames
to a multi-string entry with the DNS names of the KDCs for the realm's
KDCs.

There are several improvements on master that have not made it into a
release yet; I hope to put out a KfW 4.1 release in the next couple of
months which includes them.

 Using ksetup and logon to the kerberos real works, but I don't can
 make that deep changes on the  Windows workstations (e.g. ne
 userprofile, etc ).

I'm not sure I understand this paragraph.

 Main cause it to get running the SAP-GUI, using Kerberos to authenticate!
 Mayby someone has an idea to get this running on a simple workstation
 without domain or Kerberos membership.

I am surprised that it is not working; maybe the version of SAP GUI that
MIT distributes internally has some custom config in place.  In any case,
you should be able to set SNC_LIB to point to the gssapi32.dll library and
avoid the MSLSA: cache.

-Ben

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Kerberos delegation on Windows

[Benjamin Kaduk]

On Fri, 3 Apr 2015, Jade Koskela wrote:

 Hello all,

 I would like to use gss_store_cred_into, or some similar method, to store a
 delegated TGT into the Windows LSA cache. I tried this using Kerberos API,
 GSSAPI, but wasn't successful. I also just tried kinit -c MSLSA:. In all
 cases, when the credential for the delegated user was stored in the LSA,
 the credential cache was purged of all of the tickets for the original
 user, and new tickets were stored.
 Is there any way to store tickets from multiple users in the LSA via
 Kerberos or GSSAPI?

To clarify slightly more on what was mentioned in IRC (and get the answer
in the archives), libkrb5 (and thus the GSS interfaces) assume that the
MSLSA: cache type can only contain credentials for one client principal at
a time.  As such, trying to add new credentials using one of those
routines will have the effect of overwriting any existing credentials [for
a different client principal].

This restriction is probably not inherent to the Windows LSA itself, as
the KerbSubmitTicketMessage seems to allow submitting a ticket for a
different client principal, but I have not done any experimentation in
this area.  (It is possible that software trying to use the LSA cache
would get very confused when presented this situation, for example.)

-Ben Kaduk

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: kadmin remote as a regular user

[Benjamin Kaduk]

On Wed, 1 Apr 2015, Rainer Krienke wrote:

 The ACL file /var/lib/kerberos/krb5kdc/kadm5.acl on the server looks
 like this:
 #
 admin/admin *
 kadmin/admin*
 kadmin/ad...@myrealm.de *
 john/admin*
 john/ad...@myrealm.de*

Did you restart kadmind after changing the kadm5.acl?

-Ben Kaduk

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Switching identity using kinit/kdestroy for NFSv4 mounts doesn't work

[Benjamin Kaduk]

On Fri, 13 Mar 2015, Robert Wehn wrote:

 - - klist
   - TGT for jane@REALM
 BUT!
   - localuser can still access alice's files
   - localuser can never access jane's files
   - no new NFS service ticket fetched or needed till the end
  of the ticket lifetime

 What doesn't help:
 - - logout and login as localuser
 - - restart gssd

 What helps:
 - - Unmount NFS, remount.

 The NFS client part of the linux-kernel seems to cache the NFS service
 tickets used for every combination local UID and mounted filesystem.

I don't actually run any NFSv4 myself, but my understanding from
IRC/mailing lists is that the caching has a TTL of roughly a couple hours.

See Brandon's response as well, but from a security perspective, the
kernel NFS implementation is wrong to cache things for so long, especially
without providing a way to invalidate a cached entry.

-Ben Kaduk

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Kerberos for Windows MSLSA Cache

[Benjamin Kaduk]

On Fri, 6 Mar 2015, Christopher Penney wrote:

 On Fri, Mar 6, 2015 at 12:44 PM, Benjamin Kaduk ka...@mit.edu wrote:

 
  I believe I have fixed these bugs in the krb5 development branch, but they
  have not made it into a new KfW release yet.  If you are interested in
  building KfW from the latest sources, I would be interested to hear if
  that resolves your problems.
 
 
 That's good to know, thanks.  I might try that though I'm not much of a
 developer.  Is there any ETA (even if rough) for when this would make it to
 a released version?

It seems that some demand from this is appearing from other places as
well, so it will make its way higher on my priority list.  There is
another feature wanted for the next KfW release (better screen reader
support), so the ETA is still measured in months; I would ballpark 2
months until a beta release, but that is a very rough estimate and could
change a lot.

   I'm also experiencing a problem where (using either MSLSA: or a file for
   the CC) I can renew tickets just fine from a cmd window using 'kinit
  -R,
   but the MIT Kerberos.exe sys tray tool crashes when it tries to renew.  I
   get the following in event viewer:
 
  I am less sure about this issue.  It is possible that it is related to the
  UAC permissions mentioned above, but it may be a different issue.
 

 I should have noted this in the original note, but it seemed like it used
 to work (we've been using KfW for about 6 months), but recently broken.
 The user sample size is really small here though so it's hard to tell.  Is
 there anything I can do to help pin it down (e.g. debugging flags I'm not
 aware of)?

Most of the debugging flags are set at compile time.  The KRB5_TRACE
environment variable does work (as on Unix krb5), but I don't expect it to
provide any useful output for this situation.

Debugging runtime crashes is usually easiest with the help of a debugger,
but the release versions do not include debugging symbols.  If you want
have visual studio around and want to try, I can see about sending the
debug symbols to you.

-Ben

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Kerberos for Windows MSLSA Cache

[Benjamin Kaduk]

Hi Chris,

On Fri, 6 Mar 2015, Christopher Penney wrote:

 I run a Linux environment that's setup in an MIT Kerberos Realm. That realm
 has a one way trust setup that allows tickets for Active Directory
 principals (from Windows 7 clients) to be accepted as authentication (for
 SSH and ODBC for Hadoop/Hive).  I'm having two problems.

 The first problem I'm having is that Windows 7 users using Kerberos for
 Windows 4.01 do not seem to be able to use their AD ticket in the MSLSA
 cache. If I set KRB5CCNAME to a file and obtain an AD ticket independently
 of MSLSA everything works fine. With KRB5CCNAME set to MSLSA: it does not
 work. I did find a note about setting AllowTGTSessionKey to 1, but that's
 already been done (and rebooted).

 Is there a way to use the AD tickets stored in MSLSA using MIT KfW?  I
 assumed it was possible looking at the release notes where it says
 Integration with the Windows LSA credentials cache, but maybe that's not
 the case.

There are several bugs in KfW 4.0.1 (previous versions) with the MSLSA
handling; several operations on the cache (lcc_resolve() and
lcc_get_principal(), at least) were attempting to retrieve the full TGT
in order to get the client principal's name in the cache.  However, the
full TGT is not actually necessary to obtain the client's name.

When UAC is enabled, attempting to retrieve the TGT from the LSA fails, so
the cache is essentially unusable.  Disabling UAC is a (not very
appealing) workaround.

I believe I have fixed these bugs in the krb5 development branch, but they
have not made it into a new KfW release yet.  If you are interested in
building KfW from the latest sources, I would be interested to hear if
that resolves your problems.

 I'm also experiencing a problem where (using either MSLSA: or a file for
 the CC) I can renew tickets just fine from a cmd window using 'kinit -R,
 but the MIT Kerberos.exe sys tray tool crashes when it tries to renew.  I
 get the following in event viewer:

  Faulting application name: MIT Kerberos.exe, version: 4.0.1.2, time stamp:
  0x50c22fb6
  Faulting module name: MSVCR100.dll, version: 10.0.40219.325, time stamp:
  0x4df2bcac
  Exception code: 0xc005
  Fault offset: 0x0003c560
  Faulting process id: 0x1828
  Faulting application start time: 0x01d05782975e269d
  Faulting application path: C:\Program Files\MIT\Kerberos\bin\MIT
  Kerberos.exe
  Faulting module path: C:\Windows\system32\MSVCR100.dll
  Report Id: 631e69e6-c3c7-11e4-92c0-180373cb2112


 The exception code points to some kind of access issue, but I can't seem to
 see what it is.  Watching it with Process Monitor wasn't very interesting,
 but I'm not an expert.

 If I run MIT Kerberos.exe -renew it gives the message There was an error
 renewing tickets!.

I am less sure about this issue.  It is possible that it is related to the
UAC permissions mentioned above, but it may be a different issue.

-Ben Kaduk

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: kerberos - Kadmin does not work

[Benjamin Kaduk]

On Wed, 4 Mar 2015, arun elango wrote:

 Hi Ben,

 Thanks.

 Yes , Kpasswd can be used . But it requires users interaction in the
 console , I am looking for other methods wherein users dont need to enter
 their passwords in the console. i.e pass the parameters to the kpasswd
 console programatically .

I think we don't understand enough about the actual proposed use case to
be able to give very good advice.  If the password change is to be done
programmatically, where is the actual password string being acquired?
Under what context is this code supposed to run?

The kpasswd protocol specified in RFC 3244 does allow for a privileged
user to set another user's password.  I think the ksetpwd utility in the
same source directory as the kpasswd utility implements the client side of
that behavior, but (1) it is not built on windows and (2) I don't remember
how widely implemented the server side is, in particular the ACL checking.

 However , I heard from one of the members in the mailing list that it is
 not possible to avoid user interaction. See below for our interaction.

That is correct.

-Ben

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: kerberos - Kadmin does not work

[Benjamin Kaduk]

On Wed, 4 Mar 2015, Mauricio Tavares wrote:

 On Wed, Mar 4, 2015 at 3:02 AM, arun elango arunelang...@gmail.com wrote:
  Hi All,
 
  I would like to work with Kerberos in Windows. I have installed MIT
  Kerberos and found it to work fine. However *kadmin* , 'kadmin.local' does
  not work. I searched for the solution but couldn't find one. Please advice.
 
   What do you mean by not working? Does not run? When it tries to
 run it fails somehow?

The kadmin client is not built on windows.

-Ben Kaduk

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Mac OS X Kerberos

[Benjamin Kaduk]

On Wed, 4 Mar 2015, Markus Moeller wrote:

 Is there anywhere a guide how to work with the Mac GSS Framework ?  There
 are many functions marked as deprecated, but I could not find any
 instruction how to replace them. Example:

 error: 'krb5_init_context' is deprecated: use GSS.framework
  [-Werror,-Wdeprecated-declarations]
code = krb5_init_context(kcontext);
   ^

One workaround is to #define KERBEROS_APPLE_DEPRECATED(x) (to nothing)
before including krb5.h.

The intent of the deprecation warning is to get you to use the gss_*
routines (not the krb5_* routines), via the GSS Framework.  Existing
software written against the krb5 routines can't easily change, though.

-Ben Kaduk

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos