Re: trouble with msktutil and Windows 2008 AD

[Douglas E. Engert]

On 3/8/2011 9:19 AM, Rohit Kumar Mehta wrote:
> From reading this list, it seems like msktutil is a much better
> solution for managing Linux service principles in an AD than using
> KTPASS.EXE. However, I seem to be having some difficulties.
>
> I set up a test AD with the domain TAD.ENGR.UCONN.EDU, and I'm trying to
> create some service principles for my test-nfs server. So on my test
> Linux server (running Ubuntu Lucid), I downloaded msktutil from git (I
> believe version 0.4), compiled, did a kinit
> Admini...@TAD.ENGR.UCONN.EDU, and then tried to run msktutil.This
> is what I get:

If this is from
http://fuhm.net/software/msktutil/
I have not tried it, but it says it is based on this version:
http://download.systemimager.org/~finley/msktutil/
Which is what we are using.

>
> root@test-nfs:~/build/f/msktutil# ./msktutil --precreate --hostname
> test-nfs.tad.engr.uconn.edu -s host -s nfs --server 137.99.15.89 --verbose
> -- init_password: Wiping the computer password structure
> -- get_default_keytab: Obtaining the default keytab name:
> FILE:/etc/krb5.keytab
> -- create_fake_krb5_conf: Created a fake krb5.conf file:
> /tmp/.msktkrb5.conf-mc2Qvi
> -- reload: Reloading Kerberos Context
> -- get_short_hostname: Determined short hostname: test-nfs
> -- finalize_exec: SAM Account Name is: test-nfs$
> -- try_user_creds: Checking if default ticket cache has tickets...
> -- finalize_exec: Authenticated using method 4
>
> -- ldap_connect: Connecting to LDAP server: 137.99.15.89 try_tls=YES
> -- ldap_connect: Connecting to LDAP server: 137.99.15.89 try_tls=NO
> SASL/GSSAPI authentication started
> Error: ldap_sasl_interactive_bind_s failed (Local error)
> Error: ldap_connect failed
> --> Is your kerberos ticket expired? You might try re-"kinit"ing.
> -- ~KRB5Context: Destroying Kerberos Context
> root@test-nfs:~/build/f/msktutil#
>
> Looking at wireshark I see a bunch of errors like
> KRB5KDC_ERR_S_PRINCIPAL_UNKNOWN. It looks like msktutil is trying to
> connect get authorized for this service
> ldap/test-dc1.tad.engr.uconn.edu. Given that Microsoft Active Directory
> provides LDAP. I'm not sure why that is a problem.

I have never used the --precreate option. But msktutil will need to be run
using a Kerberos ticket for an AD admin, as it needs to update AD. So you
need to run kinit before running msktutil. (After a keytab has been created,
and you are updaqting the keys, msktutil will try and use it first.)

>
> Am I doing anything obviously wrong? If so I appreciate any help. Thanks!
>
> Rohit
>

--

Douglas E. Engert <DEEn...@anl.gov>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444

[Rohit Kumar Mehta]

Hi Doug, you are correct. I got my copy of msktutil sourced from the git
server referenced from fuhm.net.

I did not mention that I had already tried the version you referenced
(0.3.16) with a similar error. I have re-tested with that version
(0.3.16) and also watched the traffic between my test AD and my test-nfs
server with wireshark. I do see some kerberos traffic, some ldap
traffic, and that same KRB5KDC_ERR_S_PRINCIPAL_UNKNOWN for
ldap/test-dc1.tad.engr.uconn.edu

Is it possible I made a mistake configuring the AD? It does seem to be
be running an LDAP server. I'm not sure if it's supposed to have an
ldap service principal by default.

root@test-nfs:~/build/msktutil-0.3.16# kinit
Admini...@TAD.ENGR.UCONN.EDU
Password for Admini...@TAD.ENGR.UCONN.EDU:
root@test-nfs:~/build/msktutil-0.3.16# ./msktutil -c -s nfs -s host -u
--server 137.99.15.89
Error: ldap_set_option failed (Local error)
Error: ldap_connect failed
root@test-nfs:~/build/msktutil-0.3.16# ./msktutil -c -s nfs -s host -u

--server 137.99.15.89 --verbose
-- init_password: Wiping the computer password structure

-- finalize_exec: Determining user principal name
-- finalize_exec: User Principal Name is:
host/test-nfs.tad....@TAD.ENGR.UCONN.EDU

-- create_fake_krb5_conf: Created a fake krb5.conf file:

/tmp/.mskt-10521krb5.conf
-- get_krb5_context: Creating Kerberos Context
-- try_machine_keytab: Using the local credential cache:
/tmp/.mskt-10521krb5_ccache
-- try_machine_keytab: krb5_get_init_creds_keytab failed (Client not
found in Kerberos database)
-- try_machine_keytab: Unable to authenticate using the local keytab
-- try_ldap_connect: Connecting to LDAP server: 137.99.15.89
-- try_ldap_connect: Connecting to LDAP server: 137.99.15.89
SASL/GSSAPI authentication started
Error: ldap_set_option failed (Local error)
Error: ldap_connect failed
-- krb5_cleanup: Destroying Kerberos Context
-- ldap_cleanup: Disconnecting from LDAP server

-- init_password: Wiping the computer password structure

root@test-nfs:~/build/msktutil-0.3.16#

--
Rohit Mehta
Computer Engineer
University of Connecticut
Engineering Computing Services
371 Fairfield Road Unit 2031
Storrs, CT 06269-2031

Office: (860) 486 - 2331
Fax: (860) 486 - 1273

[Markus Moeller]

Try using the hostname of your AD server instead of the ip. The ldap library
might ask for ldap/<server> without reverse dns lookup of the ip to a name.
In the Wireshark trace you should see which service principal was requested.
So you should see ldap/137.99.15.89 which won't exist.

Markus

"Rohit Kumar Mehta" <roh...@engr.uconn.edu> wrote in message
news:4D7909B6...@engr.uconn.edu...

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