Cross Realm Administration?
Jeff draht
jdraht at gmail.com
Mon Jan 10 14:07:59 EST 2011
Here are my ID Attributes; Please tell me what is incorrect about
this?
userPrincipalName jdraht at LAB-PASSHE.LCL
servicePrincipalName jdraht/admin at lab.passhe.lcl
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;
root at yeoman:/etc/krb5>klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: jdraht at LAB-PASSHE.LCL
Valid starting Expires Service principal
10/01/2011 09:45 10/01/2011 19:45 krbtgt/LAB-PASSHE.LCL at LAB-
PASSHE.LCL
renew until 17/01/2011 09:45
10/01/2011 10:31 10/01/2011 19:45 ldap/drsaddcd01.lab-passhe.lcl at LAB-
PASSHE.LCL
renew until 17/01/2011 09:45
Are you saying that the userid info does not belong in there?
root at yeoman:/etc/krb5>klist -k
Keytab name: FILE:/etc/krb5/krb5.keytab
KVNO Principal
----
--------------------------------------------------------------------------
2 host/yeoman.lab-passhe.lcl at LAB-PASSHE.LCL
2 host/yeoman.lab-passhe.lcl at LAB-PASSHE.LCL
2 host/yeoman.lab-passhe.lcl at LAB-PASSHE.LCL
2 host/yeoman.lab-passhe.lcl at LAB-PASSHE.LCL
2 host/yeoman.lab-passhe.lcl at LAB-PASSHE.LCL
1 xf1adm at lab-passhe.lcl
1 xf1adm at lab-passhe.lcl
1 xf1adm at lab-passhe.lcl
1 xf1adm at lab-passhe.lcl
1 xf1adm at lab-passhe.lcl
1 xf1adm at lab-passhe.lcl
1 xf1adm at lab-passhe.lcl
4 jdraht at lab-passhe.lcl
4 jdraht at lab-passhe.lcl
4 jdraht at lab-passhe.lcl
4 jdraht at lab-passhe.lcl
4 jdraht at lab-passhe.lcl
According to Sun/Oracle, this is correct?
/etc/pam.conf
root at 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" <deeng... at anl.gov> 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/admin at 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/admin at 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/hastname at 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 Kerbe... at mit.edu
> >https://mailman.mit.edu/mailman/listinfo/kerberos
>
> --
>
> Douglas E. Engert <DEEng... at anl.gov>
> 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 -
More information about the Kerberos
mailing list