12.07.2015 Views

eTrust CA-Top Secret Security for z/OS and OS ... - SupportConnect

eTrust CA-Top Secret Security for z/OS and OS ... - SupportConnect

eTrust CA-Top Secret Security for z/OS and OS ... - SupportConnect

SHOW MORE
SHOW LESS
  • No tags were found...

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

Mapping of Foreign EnvironmentsMapping Foreign Principal NamesForeign principal names are defined on <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> to indicate the realm fromwhich the <strong>for</strong>eign user will be mapped into a local ACID. The following <strong>for</strong>mat isused <strong>for</strong> this fully qualified reference./…/<strong>for</strong>eign_realm/<strong>for</strong>eign_principal_nameThe <strong>for</strong>eign_principal_name should be defined in the <strong>for</strong>eign_realm as a localprincipal in that system. The <strong>for</strong>eign_principal_name need not be identical withits associated ACID in the <strong>for</strong>eign system.The local ACID need not be defined as a Kerberos local principal. It serves as asurrogate <strong>for</strong> security activities by the <strong>for</strong>eign principal in the local environment.The KERBLINK label provides a convenient reference in the SDT to identify therelationship. The comm<strong>and</strong> to link these entities is given below:TSS ADD(SDT) KERBLINK(kerblink)LINKNAME(‘/…/<strong>for</strong>eign_realm/<strong>for</strong>eign_principal_name’) KERBUSER(surrogat)KERBLINK—1-8 character label <strong>for</strong> the SDT record identifying the <strong>for</strong>eignprincipal relationshipLINKNAME—a fully qualified <strong>for</strong>eign principal name. The<strong>for</strong>eign_principal_name must be defined as a local_principal_name in the <strong>for</strong>eignsystem.KERBUSER—a local ACID defined to <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong>. This ACID need not existat the time that the SDT record is defined. When the <strong>for</strong>eign principal attempts toinitiate a session with the local realm, however, the ACID must be defined or anerror will result.Suppose that two <strong>for</strong>eign realms have been defined,MAJESTERIAL.CLIENT.COM <strong>and</strong> COLL<strong>OS</strong>SAL.SUCCESS.COM <strong>and</strong> we wish toestablish trust relationships locally <strong>for</strong> Kerberos principals king5 in the firstrealm, using the following comm<strong>and</strong>:TSS ADD(lscess1) KERBNAME(king5)major_major_majorIn the second realm, using the following comm<strong>and</strong>:TSS ADD(lclint1) KERBNAME(major_major_major).On the second realm, where king5 is <strong>for</strong>eign defines a <strong>for</strong>eign principal “king5”from the originating <strong>for</strong>eign realm MAJESTERIAL.CLIENT.COM <strong>and</strong> associatesthat principal locally with ACID “client1” in the local TSS.TSS ADD(SDT) KERBLINK(kclint1) LINKNAME(‘/…/majesterial.client.com/king5’)KERBUSER(client1)Implementing <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> in a z/<strong>OS</strong> or <strong>OS</strong>/390 Environment 1–89

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!