Cross Realm Administration?
Douglas E. Engert
deengert at anl.gov
Mon Jan 10 16:13:19 EST 2011
On 1/10/2011 1:07 PM, Jeff draht wrote:
> 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
Keep in mind that Kerberos principal names are case sensitive, and the Unix
commands will expect the correct case. But Windows is case insensitive
and will return the same case as was used by the caller.
So to make sure thing work as expected, use upper case for realm names,
and lower case for hostname and users. (HTTP/ is the only service
that uses an uppercase service name.)
>
> 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;
No the following is *not* a keytab, it is a ticket cache. It was created
in /tmp for root by kinit. Its a temporary file and can be deleted when
with the kdestroy command or deleted.
> 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?
No, I am saying your terminology was incorrect, the above is a ticket cache
which is short term.
>
>
The following *is* a keytab file and contains keys. Its a long term file
used by the systems daemons.
>
> 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
>
The xf1adm and jdraht entries should not be in this file as they
look like users. Also the realm name should be upper case. The host
entry is used by the login type services like dtlogin, sshd, login,
rshd and rlogind.
Use the klist -k -e to see more info about the keys.
Authorization to login to a system is obtained using /etc/passwd, NIS
or LDAP after the authentication, not be being in a keytab file.
What is in your /etc/krb5/krb5.conf file? The realm names should be upper case
even though the Windows domain name is in lower.
>
> According to Sun/Oracle, this is correct?
Yes that look reasonable. But dtlogin, dtsession, xlock, xscreensaver,
sshd-kbint, sshd-password and sshd-gssapi will all use the "other" lines.
(Look at man sshd as sshd can also use Kerberos tickets via GSSAPI
or user+password via keyboard interactive.)
You can also debug pam using a /etc/pam_debug file with something like:
debug_flags=0x37
log_priority=7
log_facility=21
This will write out a lot of stuff to syslog "local5" at "debug".
You may have to restart a daemon for this to take effect.
See
http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libpam/pam_framework.c
> /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 -
>
> ________________________________________________
> Kerberos mailing list Kerberos at mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
>
>
--
Douglas E. Engert <DEEngert at anl.gov>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
More information about the Kerberos
mailing list