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" <[email protected]> wrote in message news:[email protected]... > 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 > [email protected] > Password for [email protected]: > 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/[email protected] > -- 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# > > > > Douglas E. Engert wrote: >> >> 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 >>> [email protected], 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 >>> > > > -- > 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 > > > ________________________________________________ > Kerberos mailing list [email protected] > https://mailman.mit.edu/mailman/listinfo/kerberos > ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
