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/[email protected] (DES cbc mode with > CRC-32) > 7 host/[email protected] (DES cbc mode with RSA- > MD5) > 7 host/[email protected] (ArcFour with HMAC/md5) > 7 host/[email protected] (unsupported encryption > type 18) > 7 host/[email protected] (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 [email protected] (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:[email protected]" 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). > 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/[email protected] > 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 [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 ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
