Cross Realm Administration?

Douglas E. Engert deengert at anl.gov
Tue Jan 25 15:48:03 EST 2011 


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 at yeoman:/>klist -ke
> Keytab name: FILE:/etc/krb5/krb5.keytab
> KVNO Principal
> ----
> --------------------------------------------------------------------------
>     7 host/yeoman.lab-passhe.lcl at LAB-PASSHE.LCL (DES cbc mode with
> CRC-32)
>     7 host/yeoman.lab-passhe.lcl at LAB-PASSHE.LCL (DES cbc mode with RSA-
> MD5)
>     7 host/yeoman.lab-passhe.lcl at LAB-PASSHE.LCL (ArcFour with HMAC/md5)
>     7 host/yeoman.lab-passhe.lcl at LAB-PASSHE.LCL (unsupported encryption
> type 18)
>     7 host/yeoman.lab-passhe.lcl at 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 xf1adm at 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:xf1adm at LAB-PASSHE.LCL"

GSS names are not Kerberos names. Kerberos names are user at realm, or
service/hostname at realm. GSS has service at hostname. (The realm is not
provided to GSS, at least not to v2).

>     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-passhe.lcl at 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.
>
>
> ________________________________________________
> 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