Here are my ID Attributes; Please tell me what is incorrect about this?
userPrincipalName [email protected] servicePrincipalName jdraht/[email protected] View basic information about your computer Windows edition------------------------------------------------ Windows Server Enterprise Copyright 2007 Microsoft Corporation. All rights reserved Service Pack 2 Here is my system keytab; r...@yeoman:/etc/krb5>klist Ticket cache: FILE:/tmp/krb5cc_0 Default principal: [email protected] Valid starting Expires Service principal 10/01/2011 09:45 10/01/2011 19:45 krbtgt/lab-passhe....@lab- PASSHE.LCL renew until 17/01/2011 09:45 10/01/2011 10:31 10/01/2011 19:45 ldap/drsaddcd01.lab-passhe....@lab- PASSHE.LCL renew until 17/01/2011 09:45 Are you saying that the userid info does not belong in there? r...@yeoman:/etc/krb5>klist -k Keytab name: FILE:/etc/krb5/krb5.keytab KVNO Principal ---- -------------------------------------------------------------------------- 2 host/[email protected] 2 host/[email protected] 2 host/[email protected] 2 host/[email protected] 2 host/[email protected] 1 [email protected] 1 [email protected] 1 [email protected] 1 [email protected] 1 [email protected] 1 [email protected] 1 [email protected] 4 [email protected] 4 [email protected] 4 [email protected] 4 [email protected] 4 [email protected] According to Sun/Oracle, this is correct? /etc/pam.conf r...@yeoman:/etc>more pam.conf # #ident "@(#)pam.conf 1.31 07/12/07 SMI" # # Copyright 2007 Sun Microsystems, Inc. All rights reserved. # Use is subject to license terms. # # PAM configuration # # Unless explicitly defined, all services use the modules # defined in the "other" section. # # Modules are defined with relative pathnames, i.e., they are # relative to /usr/lib/security/$ISA. Absolute path names, as # present in this file in previous releases are still acceptable. # # Authentication management # # login service (explicit because of pam_dial_auth) # login auth requisite pam_authtok_get.so.1 login auth required pam_dhkeys.so.1 login auth required pam_unix_cred.so.1 login auth sufficient pam_krb5.so.1 login auth required pam_unix_auth.so.1 login auth required pam_dial_auth.so.1 # # rlogin service (explicit because of pam_rhost_auth) # rlogin auth sufficient pam_rhosts_auth.so.1 rlogin auth requisite pam_authtok_get.so.1 rlogin auth required pam_dhkeys.so.1 rlogin auth required pam_unix_cred.so.1 rlogin auth required pam_unix_auth.so.1 # # Kerberized rlogin service # krlogin auth required pam_unix_cred.so.1 krlogin auth required pam_krb5.so.1 # # rsh service (explicit because of pam_rhost_auth, # and pam_unix_auth for meaningful pam_setcred) # rsh auth sufficient pam_rhosts_auth.so.1 rsh auth required pam_unix_cred.so.1 # # Kerberized rsh service # krsh auth required pam_unix_cred.so.1 krsh auth required pam_krb5.so.1 # # Kerberized telnet service # ktelnet auth required pam_unix_cred.so.1 ktelnet auth required pam_krb5.so.1 # # PPP service (explicit because of pam_dial_auth) # ppp auth requisite pam_authtok_get.so.1 ppp auth required pam_dhkeys.so.1 ppp auth required pam_unix_cred.so.1 ppp auth required pam_unix_auth.so.1 ppp auth required pam_dial_auth.so.1 # # Default definitions for Authentication management # Used when service name is not explicitly mentioned for authentication # other auth requisite pam_authtok_get.so.1 other auth required pam_dhkeys.so.1 other auth required pam_unix_cred.so.1 other auth sufficient pam_krb5.so.1 other auth required pam_unix_auth.so.1 # # passwd command (explicit because of a different authentication module) # passwd auth required pam_passwd_auth.so.1 # # cron service (explicit because of non-usage of pam_roles.so.1) # cron account required pam_unix_account.so.1 # # Default definition for Account management # Used when service name is not explicitly mentioned for account management # other account requisite pam_roles.so.1 other account required pam_unix_account.so.1 other account required pam_krb5.so.1 # # Default definition for Session management # Used when service name is not explicitly mentioned for session management # other session required pam_unix_session.so.1 # # Default definition for Password management # Used when service name is not explicitly mentioned for password management # other password required pam_dhkeys.so.1 other password requisite pam_authtok_get.so.1 other password requisite pam_authtok_check.so.1 other password sufficient pam_krb5.so.1 other password required pam_authtok_store.so.1 # # Support for Kerberos V5 authentication and example configurations can # be found in the pam_krb5(5) man page under the "EXAMPLES" section. On Jan 10, 10:06 am, "Douglas E. Engert" <[email protected]> wrote: > On 1/7/2011 3:12 PM, Jeff draht wrote: > > > > > > > We are testing Single Signon; > > > I have a MS2008 KDC and AD server are one in the same, and a > > Solaris_10 ldap Client in a SAP environment which we seem to have > > partially kerberized. I can do a klist, klist -k and see my keytab... > > > single signon works for the most part, we can login and authenticate > > against the AD Server. > > We used the adjoin.sh provided by SUN/Oracle to establish a Kerberos > > Client Conenction. > > > I have even merged a few userid entries to the keytab. I can list them > > out. klist -k > > > I can kinit userid w/o issue. All ldap client commands function just > > fine... > > > I created the keytabs for one userid manually and the other I had the > > PC team create using ktpass as per the Instructios on MS TechNet. He > > created a key and I merged in on the solaris machine. I can see the > > entries just fine. > > I think you have a misunderstanding or how this should work. > User keytab files are never merged in with the system keytab! > > Services have principals, and store keys in keytabs. Keytabs are normally > accessed by servivces like login, or sshd. Users use passwords > to get tickets using kinit. (Users can use keytabs, but usually only > for cron jobs where the user is not present to type the password. > The keytab can be created locally from the password.) > > > > > What I cannot do is make kadmin work so that I can do remote kerberos > > administration or get the seam tool to authenticate? > > AD does not respond to kadmin. You have to do the AD administration > using AD tools. > > > > > > > > > When I run kadmin I get the following error; > > > We have a default REALM, i just did not want to post it all over the > > internet... > > > Authenticating as principal jdraht/ad...@realm with password. > > kadmin: Client not found in Kerberos database while initializing > > kadmin interface > > > When I run seam tool it populates 2 of 4 fields correctly and I add > > jdraht/ad...@realm and the password I get "Client not found in > > kerberos database?" > > > The PC Admins claim that all fields are correct, they show me > > snapshots. Also, they claim that the DC's replicated the info fine. > > > I am out of ideas? I have been and am reading every blog, support doc > > out there and am trying suggestions w/negres... > > Start with this old but still valuable description of how AD and Kerberos > can work together in a number od different ways: > > http://technet.microsoft.com/en-us/library/bb742433.aspx > > Keep in mind that Microsoft referees to a "user" account for the > host/hastn...@realm. This in not to be confused with Kerberos users. > > Google for: site:microsoft.com kerberos windows > > > > > Sun helped with the LDAP, but claim that kerberos and AD is not their > > area of expertise? > > > Also and this may be related, the SAP DBA's are trying to use SNC and > > there seems to be an issue there? Maybe a Library issue or related to > > the above? Not sure yet? One problem at a time? > > > Has anyone gone thru this exercise? > > > If you have any suggestions? or can point me in a direction for > > support, please advise? > > Authentication is done via Kerberos, so you also need the Sun pam_krb5. > > Authorization can then be done using: the local passwrd/shadow/group files, > NIS or LDAP. With LDAP, AD can be the server, or you could have an independent > LDAP server. You would then start to populate the LDAP database with the > data from NIS or passwd and group files. > > So to start with, get the Kerberos authentication working using users listed > in the password file. (A shadow password field of NP can be use to indicate > that no there is no password, i.e. some other method of authentication is > needed > like Kerberos.) > > > > > Thanks, Jeff > > ________________________________________________ > > Kerberos mailing list [email protected] > >https://mailman.mit.edu/mailman/listinfo/kerberos > > -- > > Douglas E. Engert <[email protected]> > Argonne National Laboratory > 9700 South Cass Avenue > Argonne, Illinois 60439 > (630) 252-5444- Hide quoted text - > > - Show quoted text -- Hide quoted text - > > - Show quoted text - ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
