Cross Realm Administration?
Jeff draht
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.
What I cannot do is make kadmin work so that I can do remote kerberos
administration or get the seam tool to authenticate?
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@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@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...
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?
Thanks, Jeff
Wilper, Ross A
2) Might you be running Windows Server 2008 without Service Pack 2 on your AD? Before SP2 there was a bug that prevented any account with a "/" from authenticating.
-Ross
Thanks, Jeff
________________________________________________
Kerberos mailing list Kerb...@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
Douglas E. Engert
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@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@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@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 Kerb...@mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
>
>
--
Douglas E. Engert <DEEn...@anl.gov>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
Jeff draht
this?
userPrincipalName jdr...@LAB-PASSHE.LCL
servicePrincipalName jdraht/ad...@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@yeoman:/etc/krb5>klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: jdr...@LAB-PASSHE.LCL
Valid starting Expires Service principal
10/01/2011 09:45 10/01/2011 19:45 krbtgt/LAB-PASSHE.LCL@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@LAB-
PASSHE.LCL
renew until 17/01/2011 09:45
Are you saying that the userid info does not belong in there?
root@yeoman:/etc/krb5>klist -k
Keytab name: FILE:/etc/krb5/krb5.keytab
KVNO Principal
----
--------------------------------------------------------------------------
2 host/yeoman.lab...@LAB-PASSHE.LCL
2 host/yeoman.lab...@LAB-PASSHE.LCL
2 host/yeoman.lab...@LAB-PASSHE.LCL
2 host/yeoman.lab...@LAB-PASSHE.LCL
2 host/yeoman.lab...@LAB-PASSHE.LCL
1 xf1...@lab-passhe.lcl
1 xf1...@lab-passhe.lcl
1 xf1...@lab-passhe.lcl
1 xf1...@lab-passhe.lcl
1 xf1...@lab-passhe.lcl
1 xf1...@lab-passhe.lcl
1 xf1...@lab-passhe.lcl
4 jdr...@lab-passhe.lcl
4 jdr...@lab-passhe.lcl
4 jdr...@lab-passhe.lcl
4 jdr...@lab-passhe.lcl
4 jdr...@lab-passhe.lcl
According to Sun/Oracle, this is correct?
/etc/pam.conf
root@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.
> > Kerberos mailing list Kerbe...@mit.edu
> >https://mailman.mit.edu/mailman/listinfo/kerberos
>
> --
>
> Douglas E. Engert <DEEng...@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 -
Douglas E. Engert
On 1/10/2011 1:07 PM, Jeff draht wrote:
> Here are my ID Attributes; Please tell me what is incorrect about
> this?
>
>
> userPrincipalName jdr...@LAB-PASSHE.LCL
> servicePrincipalName jdraht/ad...@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@yeoman:/etc/krb5>klist
> Ticket cache: FILE:/tmp/krb5cc_0
> Default principal: jdr...@LAB-PASSHE.LCL
>
> Valid starting Expires Service principal
> 10/01/2011 09:45 10/01/2011 19:45 krbtgt/LAB-PASSHE.LCL@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@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@yeoman:/etc/krb5>klist -k
> Keytab name: FILE:/etc/krb5/krb5.keytab
> KVNO Principal
> ----
> --------------------------------------------------------------------------
> 2 host/yeoman.lab...@LAB-PASSHE.LCL
> 2 host/yeoman.lab...@LAB-PASSHE.LCL
> 2 host/yeoman.lab...@LAB-PASSHE.LCL
> 2 host/yeoman.lab...@LAB-PASSHE.LCL
> 2 host/yeoman.lab...@LAB-PASSHE.LCL
> 1 xf1...@lab-passhe.lcl
> 1 xf1...@lab-passhe.lcl
> 1 xf1...@lab-passhe.lcl
> 1 xf1...@lab-passhe.lcl
> 1 xf1...@lab-passhe.lcl
> 1 xf1...@lab-passhe.lcl
> 1 xf1...@lab-passhe.lcl
> 4 jdr...@lab-passhe.lcl
> 4 jdr...@lab-passhe.lcl
> 4 jdr...@lab-passhe.lcl
> 4 jdr...@lab-passhe.lcl
> 4 jdr...@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
> ________________________________________________
> Kerberos mailing list Kerb...@mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
>
>
--
Douglas E. Engert <DEEn...@anl.gov>
Jeff draht
I understand the /tmp for the ticket cache of the user
that is logged in.
However, I do not understand you indicating that
the /etc/krb5/krb5.keytab is not the keytab file?
The output of this file is diaplayed by a "klist -k"
"klist" seems to show the ticket cache for the user
running the command.
/tmp/krb5cc_uid Default credentials cache (uid is
the decimal UID of the user).
/etc/krb5/krb5.keytab Default location for the local
host's keytab file.
/etc/krb5/krb5.conf Default location for the local
host's configuration file. See
krb5.conf(4).
Jeff draht
It looks like others, similar to the Docs?
[realms]
LAB-PASSHE.LCL = {
kdc = drsaddcd01.lab-passhe.lcl
admin_server = drsaddcd01.lab-passhe.lcl
kdc = drsaddcd01.lab-passhe.lcl
kdc = drsaddcd02.lab-passhe.lcl
kdc = drsaddcd03.lab-passhe.lcl
kpasswd_server = drsaddcd01.lab-passhe.lcl
kpasswd_protocol = SET_CHANGE
}
[domain_realm]
.lab-passhe.lcl = LAB-PASSHE.LCL
lab-passhe.lcl = LAB-PASSHE.LCL
Regarding the system keytab file? /etc/krb5/krb5.keytab
So I am understanding it to be for Services only?
ex:
ldap/drsaddcd01.l...@LAB-PASSHE.LCL
host/yeoman.lab...@LAB-PASSHE.LCL
krbtgt/LAB-PAS...@LAB-PASSHE.LCL
The please explain a personal keytab?
So the AD Server creates the keytab.
I have a request from SAP to create a personal keytab for userid
xf1adm?
This is what they are asking for?
So the keytab is created by the AD Server using ktpass?
Then I take it on the unix machine and run the kinit command?
I must save that keytab then and point xf1adm to always look at it?
KRB5_KTNAME=/<directory>/xf1.keytab.MD5.SUN (location of the keytab)
kinit -k -t /<directory>/xf1.keytab.MD5.SUN xf1...@passhe.edu
Douglas E. Engert
On 1/13/2011 9:25 AM, Jeff draht wrote:
> Here is the piece you requested to view in my /etc/krb5/krb5.conf
>
> It looks like others, similar to the Docs?
>
> [realms]
> LAB-PASSHE.LCL = {
> kdc = drsaddcd01.lab-passhe.lcl
> admin_server = drsaddcd01.lab-passhe.lcl
> kdc = drsaddcd01.lab-passhe.lcl
> kdc = drsaddcd02.lab-passhe.lcl
> kdc = drsaddcd03.lab-passhe.lcl
> kpasswd_server = drsaddcd01.lab-passhe.lcl
> kpasswd_protocol = SET_CHANGE
>
> }
> [domain_realm]
> .lab-passhe.lcl = LAB-PASSHE.LCL
> lab-passhe.lcl = LAB-PASSHE.LCL
>
>
>
>
> Regarding the system keytab file? /etc/krb5/krb5.keytab
>
> So I am understanding it to be for Services only?
It is for the services running on the local computer.
> ex:
>
> ldap/drsaddcd01.l...@LAB-PASSHE.LCL
> host/yeoman.lab...@LAB-PASSHE.LCL
> krbtgt/LAB-PAS...@LAB-PASSHE.LCL
So on yeoman, it should *only* have entries for
services run on yeoman:
host/yeoman.lab...@LAB-PASSHE.LCL
It should *NOT* have the krbtgt/LAB-PAS...@LAB-PASSHE.LCL
or the ldap/drsaddcd01.l...@LAB-PASSHE.LCL as they
are the keys for the AD server!
Kerberos is a third party between a user and a server. Only the
KDC and the user know the user's secret. Only the server and the
KDC know the server's secret. Giving away the
krbtgt/LAB-PAS...@LAB-PASSHE.LCL key would allow anyone to
impersonate any user to any service in the domain!
>
>
> The please explain a personal keytab?
The encryption keys use by Kerberos are a function of the password
Key = string_to_key(PW, salt)
where salt depends on the key type and principal name. (for RC4
there is no salt, for DES and AES it is a string composed of the
components of the principal.)
So given the password and salt, one can derive a key at any time.
Windows tends to derive keys when they are needed. i.e. the password
is stored in the AD account for the user or service. The user knows
their password, and client machines and services have a password buried
in the registry.
Other Kerberos implementations generate the key once when the principal
is enrolled, or the password in the KDC. Users know their passwords
but not keys, so nothing needs be stored long term on a client about
a user. But services could store a password, but a key is normally
stored instead in a keytab file. (There is not reverse function for
PW=f(Key)) so there is some additional security in storing keys.)
So the situation where a user would use a keytab, would only be
in situations where the user could not enter a password, such as
for use with cron jobs.
> So the AD Server creates the keytab.
What usually happens is an AD admin creates the keytab for a service
and updates the AD account at the same time. This keeps them in
sync.(There is also a key version number (KVNO) that gets incremented.
In AD it is stored as the msDS-keyVersionNumber attribute.
ktpass can update both at the same time, and can use a randomly
chosen password.
But this could be a two step process. An AD account is created and
a password is set by some AD admin. At some other time ktutil could
be run by a unix user to create a keytab using the same password
and kvno that AD has stored. So a user could create their own
keytab.
Keep in mind that if the password is changed in AD, the keytab need
to be changed.
>
> I have a request from SAP to create a personal keytab for userid
> xf1adm?
> This is what they are asking for?
I don't know SAP, but that is what it sounds like.
>
> So the keytab is created by the AD Server using ktpass?
It the account is already setup, thne the user or root) on the
unix machine could create the keytab.
> Then I take it on the unix machine and run the kinit command?
>
> I must save that keytab then and point xf1adm to always look at it?
xf11adm could still use the password if the password is known.
>
>
> KRB5_KTNAME=/<directory>/xf1.keytab.MD5.SUN (location of the keytab)
>
You probably don't want to set KRB5_KTNAME if you are going to
use the kinit -k -t ...
But read the SAP documentation. They may be calling kinit internally
or using the principal and keytab as a service.
> kinit -k -t /<directory>/xf1.keytab.MD5.SUN xf1...@passhe.edu
>
>
Douglas E. Engert
On 1/12/2011 9:03 AM, Jeff draht wrote:
> Here is the manpage for kinit.
>
> I understand the /tmp for the ticket cache of the user
> that is logged in.
>
> However, I do not understand you indicating that
> the /etc/krb5/krb5.keytab is not the keytab file?
Some misunderstanding. /etc/krb5/krb5.keytab is the
system's keytab file, and should be readable only by root.
If you have other services not running as root, and
they need a keytab file, the keytab file should be
owned by the UID running the service. Or if the user has
a keytab file it should readable only be the user.
>
> The output of this file is diaplayed by a "klist -k"
>
> "klist" seems to show the ticket cache for the user
> running the command.
It can show ticket caches or keytab files.
>
> /tmp/krb5cc_uid Default credentials cache (uid is
> the decimal UID of the user).
>
> /etc/krb5/krb5.keytab Default location for the local
> host's keytab file.
>
> /etc/krb5/krb5.conf Default location for the local
> host's configuration file. See
> krb5.conf(4).
Jeff draht
When we initially installed this, As per the Oracle
Engineer,
his skill set was very limited in Kerberos.
It has been a challenge to gather info on Kerberos Admin Procedures
As a result.
Oracle's Scope was to get us Connected (Solaris LDAP Client)
Authenticate against AD 2008 and Kerberos via Adjoin script.
For the most part, this was accomplished.
It did leave us with a limited understanding of the entire process
And how to properly Manage/Administer it?
I have requested Training (Onsite for a group) and/or maybe a
Professional Services Engagement.
However, we have come a long way is a short period of time and
I feel like I have a fairly good grasp (Thx to some information from
you)
of the process but still have Many unanswered questions...
I believe that you indicated that the "kadmin" cannot work from the
Sun Ldap Client when AD/KDC are Windows Based Servers?
Nowhere do I see that stated on the Oracle Website?
They do seem to push the Seam Tool for all types of
environments... I am curious if my userid needs to be in the
Domain Admin group to use the Seam Tool? It errors...
I have cleaned up my System Keytab, had the AD Admin create
a new one... I recommended to use the -encrypt -All command
in ktpass to obtain all encryption types. Below is how it is now and
was at initial installation.
root@yeoman:/>klist -ke
Keytab name: FILE:/etc/krb5/krb5.keytab
KVNO Principal
----
--------------------------------------------------------------------------
7 host/yeoman.lab...@LAB-PASSHE.LCL (DES cbc mode with
CRC-32)
7 host/yeoman.lab...@LAB-PASSHE.LCL (DES cbc mode with RSA-
MD5)
7 host/yeoman.lab...@LAB-PASSHE.LCL (ArcFour with HMAC/md5)
7 host/yeoman.lab...@LAB-PASSHE.LCL (unsupported encryption
type 18)
7 host/yeoman.lab...@LAB-PASSHE.LCL (AES-128 CTS mode with
96-bit SHA-1 HMAC)
I see that the KVNO # is now 7?
How can I ask the AD Admin to sync this up between the Solaris Ldap
Client and AD- KDC?
What verbage should I use to communicate that to him?
I believe I have a good grasp on the user keytab file creation and
process?
So when I do this below, it keeps it in cache for the session and it
is not necessary to do any other commands If I understand it
correctly?
klist -k -e -t /var/tmp/xf1adm.keytab
Keytab name: FILE:/var/tmp/xf1adm.keytab
KVNO Timestamp Principal
---- ----------------
----------------------------------------------------------
7 24/01/2011 15:14 xf1...@LAB-PASSHE.LCL (ArcFour with HMAC/md5)
Also, the SAP DBA's believe that they are having an issue with a SNC
Library
and need a MIT Kerberos 5 Library? Any Thoughts?
115 N File "/usr/sap/XF1/SYS/exe/run/libsapcrypto.so"
dynamically loade
d as GSS-API v2 library.
116 N The internal Adapter for the loaded GSS-API mechanism
identifies
as:
117 N Internal SNC-Adapter (Rev 1.0) to SECUDE 5/GSS-API v2
118 N *** ERROR => SncPGSSImportName()==SNCERR_GSSAPI
[sncxxall.c 2630]
119 N GSS-API(maj): An invalid name was supplied
120 N Import of a name failed
121 N name="p:xf1...@LAB-PASSHE.LCL"
122 N <<- SncInit()==SNCERR_GSSAPI
123 N sec_avail = "false"
124 M ***LOG R19=> ThSncInit, SncInitU ( SNC-000004)
[thxxsnc.c 230]
125 M *** ERROR => ThSncInit: SncInitU (SNCERR_GSSAPI)
[thxxsnc.c 232]
126 M in_ThErrHandle: 1
127 M *** ERROR => SncInitU (step 1, th_errno 44, action 3, level
1) [thx
xhead.c 10607]
128 M
F.Y.I.
LAB-PASSHE.LCL is our test environment, so we are not using passhe.edu
the primary Windows Domain is PASSHE.LCL but all are linked to
passhe.edu
I wanted to bring something to your attention?
I have noticed some changes to the AD Account Yeoman and my Userid?
At present we are having some communication issues and I believe it
is related? I am not Administering our AD-KDC, please keep in mind...
Here is the Initial Post Install Config and Current for Yeoman
differences that
I want to point out;
I believe that the Service Principal naming is wrong and the user
principal in missing?
Current Yeoman Properties on AD Server.
------------------------------------------------------------
sAMAccountName: YEOMAN$
sAMAccountType: 805306369
dNSHostName: yeoman.lab-passhe.lcl
servicePrincipalName: HOST/YEOMAN.LAB-PASSHE.LCL
servicePrincipalName: HOST/YEOMAN
objectCategory: CN=Computer,CN=Schema,CN=Configuration,DC=LAB-
PASSHE,DC=LCL
isCriticalSystemObject: FALSE
dSCorePropagationData: 16010101000000.0Z
lastLogonTimestamp: 129393723014479313
msDS-SupportedEncryptionTypes: 18
Yeoman Post Installation Initial Config
-----------------------------------------------
sAMAccountName: YEOMAN$
sAMAccountType: 805306369
dNSHostName: yeoman.lab-passhe.lcl
userPrincipalName: host/yeoman.lab...@LAB-PASSHE.LCL
servicePrincipalName: host/yeoman.lab-passhe.lcl
objectCategory: CN=Computer,CN=Schema,CN=Configuration,DC=LAB-
PASSHE,DC=LCL
isCriticalSystemObject: FALSE
dSCorePropagationData: 16010101000000.0Z
lastLogonTimestamp: 129356911380595383
msDS-SupportedEncryptionTypes: 18
Domain Admin is not present currently?
Current Properties, jdraht
----------------------------------------
memberOf: CN=SYT-HelpDesk,OU=Roles,OU=SYT,OU=Campuses,DC=LAB-
PASSHE,DC=LCL
memberOf: CN=SYT-TeamSytec-
OS,OU=Security,OU=Groups,OU=SYT,OU=Campuses,DC=LAB-
PASSHE,DC=LCL
uSNChanged: 2443251
name: Draht,Jeff.
jdraht Properties, post install initial
--------------------------------------------------
memberOf: CN=SYT-TeamSytec-
OS,OU=Security,OU=Groups,OU=SYT,OU=Campuses,DC=LAB-
PASSHE,DC=LCL
memberOf: CN=Domain Admins,CN=Users,DC=LAB-PASSHE,DC=LCL
uSNChanged: 2144812
name: Draht,Jeff.
Jeff draht
kinit -k -t /var/tmp/xf1adm.keytab xf1...@LAB-PASSHE.LCL
kinit(v5): Key table entry not found while getting initial credentials
Douglas E. Engert
On 1/25/2011 12:52 PM, Jeff draht wrote:
> Doug,
> When we initially installed this, As per the Oracle
> Engineer,
> his skill set was very limited in Kerberos.
>
> It has been a challenge to gather info on Kerberos Admin Procedures
> As a result.
Maybe you should be asking your questions on the
http://mail.opensolaris.org/mailman/listinfo/kerberos-discuss
>
> Oracle's Scope was to get us Connected (Solaris LDAP Client)
> Authenticate against AD 2008 and Kerberos via Adjoin script.
> For the most part, this was accomplished.
>
> It did leave us with a limited understanding of the entire process
> And how to properly Manage/Administer it?
Use AD commands to administer AD if at all possible.
>
> I have requested Training (Onsite for a group) and/or maybe a
> Professional Services Engagement.
Good!
>
> However, we have come a long way is a short period of time and
> I feel like I have a fairly good grasp (Thx to some information from
> you)
> of the process but still have Many unanswered questions...
>
> I believe that you indicated that the "kadmin" cannot work from the
> Sun Ldap Client when AD/KDC are Windows Based Servers?
I believe so. Use AD tools to administer AD if possible.
You can use ldap to do some administration. Here is an example
of a search:
/usr/bin/ldapsearch -o mech=GSSAPI -o authzid= -h name.of.a.domain.controller \
-p 389 -b "DC=LAB-PASSHE,DC=LCL" "(dNSHostName=yeoman.lab-passhe.lcl)" "*"
(Note the authzid= has no paramater.) You should then see that the
user who ran this now has a ticket for the ldap/name.of.a.domain.controller
>
> Nowhere do I see that stated on the Oracle Website?
> They do seem to push the Seam Tool for all types of
> environments... I am curious if my userid needs to be in the
> Domain Admin group to use the Seam Tool? It errors...
userid may be the wrong term here as is a unix concept.
Your user account may need to be in the admin groups or need
rights in parts of AD to update entries and attributes.
>
> I have cleaned up my System Keytab, had the AD Admin create
> a new one... I recommended to use the -encrypt -All command
> in ktpass to obtain all encryption types. Below is how it is now and
> was at initial installation.
>
> root@yeoman:/>klist -ke
> Keytab name: FILE:/etc/krb5/krb5.keytab
> KVNO Principal
> ----
> --------------------------------------------------------------------------
> 7 host/yeoman.lab...@LAB-PASSHE.LCL (DES cbc mode with
> CRC-32)
> 7 host/yeoman.lab...@LAB-PASSHE.LCL (DES cbc mode with RSA-
> MD5)
> 7 host/yeoman.lab...@LAB-PASSHE.LCL (ArcFour with HMAC/md5)
> 7 host/yeoman.lab...@LAB-PASSHE.LCL (unsupported encryption
> type 18)
> 7 host/yeoman.lab...@LAB-PASSHE.LCL (AES-128 CTS mode with
> 96-bit SHA-1 HMAC)
>
> I see that the KVNO # is now 7?
> How can I ask the AD Admin to sync this up between the Solaris Ldap
> Client and AD- KDC?
You lost me here. Servers use keytabs. Client use ticket caches.
So if the ldap client need to contact its LDAP server, AD I presume,
the client does not need a keytab. You should not need a keytab for
the LDAP server.
> What verbage should I use to communicate that to him?
I don't think he has to do anything.
>
> I believe I have a good grasp on the user keytab file creation and
> process?
> So when I do this below, it keeps it in cache for the session and it
> is not necessary to do any other commands If I understand it
> correctly?
>
> klist -k -e -t /var/tmp/xf1adm.keytab
> Keytab name: FILE:/var/tmp/xf1adm.keytab
> KVNO Timestamp Principal
> ---- ----------------
> ----------------------------------------------------------
> 7 24/01/2011 15:14 xf1...@LAB-PASSHE.LCL (ArcFour with HMAC/md5)
I still don't understand why you thing you need a keytab fot this xf1adm.
>
> Also, the SAP DBA's believe that they are having an issue with a SNC
> Library
> and need a MIT Kerberos 5 Library? Any Thoughts?
Don't know SAP or what a SNC library is. Try asking on a SAP list.
>
>
> 115 N File "/usr/sap/XF1/SYS/exe/run/libsapcrypto.so"
> dynamically loade
> d as GSS-API v2 library.
> 116 N The internal Adapter for the loaded GSS-API mechanism
> identifies
> as:
> 117 N Internal SNC-Adapter (Rev 1.0) to SECUDE 5/GSS-API v2
> 118 N *** ERROR => SncPGSSImportName()==SNCERR_GSSAPI
> [sncxxall.c 2630]
> 119 N GSS-API(maj): An invalid name was supplied
> 120 N Import of a name failed
> 121 N name="p:xf1...@LAB-PASSHE.LCL"
GSS names are not Kerberos names. Kerberos names are user@realm, or
service/hostname@realm. GSS has service@hostname. (The realm is not
provided to GSS, at least not to v2).
Jeff draht
this is the issue I am having after creating a users keytab
file;
ktutil: addent -password -p xf1...@LAB-PASSHE.LCL -k 7 -e arcfour-
hmac-md5
Password for xf1...@LAB-PASSHE.LCL:
ktutil: list
slot KVNO Principal
---- ----
---------------------------------------------------------------------
1 7 xf1...@LAB-PASSHE.LCL
ktutil: wkt /var/tmp/xf1adm-keytab-new-012511
ktutil: q
root@yeoman:/usr/local/bin>klist -ke /var/tmp/xf1adm-keytab-new-012511
----
--------------------------------------------------------------------------
7 xf1...@LAB-PASSHE.LCL (ArcFour with HMAC/md5)
Then;
kinit –k –t /var/tmp/xf1adm-keytab-new-012511 xf1...@LAB-PASSHE.LCL
However, this function does not work; it errors;
kinit -k -t /var/tmp/xf1adm-keytab-new-012511 xf1...@LAB-PASSHE.LCL
kinit(v5): Key table entry not found while getting initial credentials
Thanks and I will start using the link you suggested for my
questions...
Jeff
Douglas E. Engert
I ran into a problem like this in 2009, on Solaris 10 client to AD 2008
involving AES256.
I think what might be going on is the kinit sends the AS-REQ message
to the KDC with a list of supported enctypes. The KDC then picks the best
enctype supported for that principal and returns the ticket.
If the client send AES, and the KDC supports it, then an AES key will
be needed. The problem is the kinit does not look to see what encytes
are available in the keytab. When using a password, kinit can generate
a key for any enctype from the password so this is not an issue.
The way to see if this is the case is to use Wireshark or other
network trace program on the client. You should see the KRB5 packets
and can see the AS-REQ being sent and the enctypes that are supported.
The AS-REP from the KDC will contain a ticket which is encrypted
for the use by the client principal. I bet it says it is looking
for something other the ArcFour, or the kvno does not match.
Ways around this:
Look at the msDS-SupportedEncryptionTypes attribute on the
xf1adm AD account. (Look at the msDS-KeyVersionNumber too.)
See:
http://msdn.microsoft.com/en-us/library/cc223853(v=prot.13).aspx
This could be changed in AD for the client to only support ArcFour.
Or the keytab entry could have AES256. But if you are using the SAP
client later, make sure SAP can support AES256 too, as it will need
to use the krbtgt ticket to get more tickets.
>
> Thanks and I will start using the link you suggested for my
> questions...
>
> Jeff