Lines Matching full:realm
3 @node Setting up a realm, Applications, Building and Installing, Top
5 @chapter Setting up a realm
8 @cindex realm
9 realm is an administrative domain. The name of a Kerberos realm is
10 usually the Internet domain name in uppercase. Call your realm the same
27 * Cross realm::
36 @node Configuration file, Creating the database, Setting up a realm, Setting up a realm
39 To setup a realm you will first have to create a configuration file:
78 parameters, such as the default realm and the timeout for KDC
86 To continue with the realm setup, you will have to create a configuration file,
91 default_realm = MY.REALM
93 MY.REALM = @{
100 .my.domain = MY.REALM
104 If you use a realm name equal to your domain name, you can omit the
106 SRV-record for your realm, or your Kerberos server has DNS CNAME
107 @samp{kerberos.my.realm}, you can omit the @samp{realms} section too.
114 env KRB5_CONFIG=$HOME/etc/krb5.conf kinit user@@REALM
117 @node Creating the database, Modifying the database, Configuration file, Setting up a realm
149 @kbd{init MY.REALM} command. This will create the database and insert
150 default principals for that realm. You can have more than one realm in
158 principal. The principal should contain a realm, so if you haven't set up
159 a default realm, you will need to explicitly include the realm.
163 kadmin> init MY.REALM
164 Realm max ticket life [unlimited]:
165 Realm max renewable ticket life [unlimited]:
182 Principal: me@@MY.REALM
185 Aug 25 07:25:55 Aug 25 17:25:55 krbtgt/MY.REALM@@MY.REALM
195 me@@MY.REALM 1:0:1:0b01d3cb7c293b57:-:0:7:8aec316b9d1629e3baf8 ...
196 kadmin/admin@@MY.REALM 1:0:1:e5c8a2675b37a443:-:0:7:cb913ebf85 ...
197 krbtgt/MY.REALM@@MY.REALM 1:0:1:52b53b61c875ce16:-:0:7:c8943be ...
198 kadmin/changepw@@MY.REALM 1:0:1:f48c8af2b340e9fb:-:0:7:e3e6088 ...
201 @node Modifying the database, Checking the setup, Creating the database, Setting up a realm
231 Principal: me@@MY.REALM
263 @node Checking the setup, keytabs, Modifying the database, Setting up a realm
281 kadmin -l check REALM.EXAMPLE.ORG
284 @node keytabs, Remote administration, Checking the setup, Setting up a realm
301 1 des-cbc-md5 host/my.host.name@@MY.REALM
302 1 des-cbc-md4 host/my.host.name@@MY.REALM
303 1 des-cbc-crc host/my.host.name@@MY.REALM
304 1 des3-cbc-sha1 host/my.host.name@@MY.REALM
307 @node Remote administration, Password changing, keytabs, Setting up a realm
346 the realm @samp{E.KTH.SE}. @samp{mille/admin} is working at the
358 @node Password changing, Testing clients and servers, Remote administration, Setting up a realm
365 @samp{464/udp}. If your realm is not setup to use DNS, you might also
366 need to add a @samp{kpasswd_server} entry to the realm configuration
371 MY.REALM = @{
468 @node Testing clients and servers, Slave Servers, Password changing, Setting up a realm
474 @node Slave Servers, Incremental propagation, Testing clients and servers, Setting up a realm
475 @section Slave servers, Incremental propagation, Testing clients and servers, Setting up a realm
481 All Kerberos servers for a realm must have the same database so that
526 @node Incremental propagation, Encryption types and salting, Slave Servers, Setting up a realm
599 …ption types and salting, Credential cache server - KCM, Incremental propagation, Setting up a realm
620 (none at all) or the afs-salt (using the cell (realm in
660 @node Credential cache server - KCM, Cross realm, Encryption types and salting, Setting up a realm
729 @node Cross realm, Transit policy, Credential cache server - KCM, Setting up a realm
730 @section Cross realm
731 @cindex Cross realm
733 Suppose you reside in the realm @samp{MY.REALM}, how do you
734 authenticate to a server in @samp{OTHER.REALM}? Having valid tickets in
735 @samp{MY.REALM} allows you to communicate with Kerberised services in that
736 realm. However, the computer in the other realm does not have a secret
737 key shared with the Kerberos server in your realm.
741 finds that the other computer is in a different realm, it will try to
742 get a ticket granting ticket for that other realm, but from the local
744 service tickets from the Kerberos server in the other realm.
746 For a two way trust between @samp{MY.REALM} and @samp{OTHER.REALM}
747 add the following principals to each realm. The principals should be
748 @samp{krbtgt/OTHER.REALM@@MY.REALM} and
749 @samp{krbtgt/MY.REALM@@OTHER.REALM} in @samp{MY.REALM}, and
750 @samp{krbtgt/MY.REALM@@OTHER.REALM} and
751 @samp{krbtgt/OTHER.REALM@@MY.REALM}in @samp{OTHER.REALM}.
754 users from @samp{MY.REALM} can authenticate to services in
755 @samp{OTHER.REALM}, but not the opposite. In the example above, the
756 @samp{krbtgt/MY.REALM@@OTHER.REALM} then should be removed.
792 @node Transit policy, Setting up DNS, Cross realm, Setting up a realm
797 cross-realm trust with every realm to which you wish to authenticate
799 multi-hop cross-realm trust where a client principal in realm A
800 authenticates to a service in realm C through a realm B with which
801 both A and C have cross-realm trust relationships. In this situation,
802 A and C need not set up cross-realm principals between each other.
804 If you want to use cross-realm authentication through an intermediate
805 realm, it must be explicitly allowed by either the KDCs for the realm
806 to which the client is authenticating (in this case, realm C), or the
810 In addition, the client in realm A need to be configured to know how
811 to reach realm C via realm B. This can be done either on the client or
812 via KDC configuration in the KDC for realm A.
814 @subsection Allowing cross-realm transits
816 When the ticket transits through a realm to another realm, the
817 destination realm adds its peer to the "transited-realms" field in the
820 authentication to be accepted by the final destination realm, all of
822 configuration, either in the KDC for the destination realm or on the
829 CLIENT-REALM = @{
830 SERVER-REALM = PERMITTED-CROSS-REALMS ...
834 In the following example, the realm @code{STACKEN.KTH.SE} only has
835 direct cross-realm set up with @code{KTH.SE}. @code{KTH.SE} has
836 direct cross-realm set up with @code{STACKEN.KTH.SE} and @code{SU.SE}.
837 @code{DSV.SU.SE} only has direct cross-realm set up with @code{SU.SE}.
854 The first entry allows cross-realm authentication from clients in
856 @code{STACKEN.KTH.SE}. The second entry allows cross-realm
860 Be careful of which realm goes where; it's easy to put realms in the
861 wrong place. The block is tagged with the client realm (the realm of
862 the principal authenticating), and the realm before the equal sign is
863 the final destination realm: the realm to which the client is
868 doing transit cross realm verification.
870 @subsection Configuring client cross-realm transits
873 clients which realm to transit through to reach a realm with which
874 their local realm does not have cross-realm trust. This can be done
877 client's local realm. In the latter case, the KDC will then hand back
878 a referral to the client when the client requests a cross-realm ticket
879 to the destination realm, telling the client to try to go through an
880 intermediate realm.
883 is significant, since only the first realm in this section (after the
887 case of a client in the @code{SU.SE} realm, and assume that the client
890 @code{STACKEN.KTH.SE} realm, that entry says to first authenticate
891 cross-realm to the @code{KTH.SE} realm (the first realm listed in the
896 the first realm in @code{PERMITTED-CROSS-REALMS} is used. If, for
910 configuration is to have one top-level Active Directory realm but then
912 on organizational unit). One generally establishes cross-realm trust
913 only with the top-level realm, and then uses transit policy to permit
916 For example, suppose an organization has a Heimdal realm
917 @code{EXAMPLE.COM}, a Windows Active Directory realm
941 the @code{EXAMPLE.COM} realm. The third block tells the client (or
944 configuration are needed for bi-directional transited cross-realm
947 @c To test the cross realm configuration, use:
950 @node Setting up DNS, Using LDAP to store the database, Transit policy, Setting up a realm
957 realm in the @file{krb5.conf} for a realm, that information will be
960 Heimdal will try to use DNS to find the KDCs for a realm. First it
961 will try to find a @code{SRV} resource record (RR) for the realm. If no
963 a machine named kerberos.REALM, and then kerberos-1.REALM, etc
975 An example of the configuration for the realm @code{EXAMPLE.COM}:
992 @subsection Using DNS to map hostname to Kerberos realm
994 Heimdal also supports a way to lookup a realm from a hostname. This to
997 same cross realm trust and made to believe they are talking to the
1001 it.example.com and srv.example.com, they should use the realm
1012 …atabase, Providing Kerberos credentials to servers and programs, Setting up DNS, Setting up a realm
1130 Realm max ticket life [unlimited]:
1131 Realm max renewable ticket life [unlimited]:
1182 … Kerberos credentials to servers and programs, Using LDAP to store the database, Setting up a realm
1185 The Samba domain and the Kerberos realm can have different names since
1186 arcfour's string to key functions principal/realm independent. So now
1187 will be your first and only chance name your Kerberos realm without
1196 …s to servers and programs, Setting up PK-INIT, Using LDAP to store the database, Setting up a realm
1243 …gging Kerberos problems, Providing Kerberos credentials to servers and programs, Setting up a realm
1274 name of the TGS of the target realm. Also, if the certificate has a
1328 realm [0] Realm,
1333 where Realm and PrincipalName is defined by the Kerberos ASN.1
1504 name of the krbtgt of the realm.
1571 realm = EXP:0, GeneralString:MY.REALM
1619 MY.MS.REALM = @{
1642 @node Debugging Kerberos problems, , Setting up PK-INIT, Setting up a realm