Lines Matching +full:realm +full:-
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
26 * Credential cache server - KCM::
27 * Cross realm::
32 * Setting up PK-INIT::
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:
48 @samp{[@samp{section-name}]}. A binding consists of a left hand side, an equal sign
51 @samp{@{} as the first non-whitespace character after the equal sign. All
57 a-subsection = @{
59 other-var = value with @{@}
60 sub-sub-section = @{
70 separated by slashes (@samp{/}). The @samp{other-var} variable will thus
71 be @samp{section1/a-subsection/other-var}.
73 For in-depth information about the contents of the configuration file, refer to
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
131 be stored in a file (@file{/var/heimdal/m-key}). If you want to have a
137 Verifying password - Master key:
141 @kbd{--random-key} flag to kstash. This will make sure you have a good key
148 @kbd{-l} option (to enable local database mode). First issue a
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.
162 # kadmin -l
163 kadmin> init MY.REALM
164 Realm max ticket life [unlimited]:
165 Realm max renewable ticket life [unlimited]:
171 Verifying password - Password:
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
210 Both interactive editing and command line flags can be used (use --help
221 Attributes are removed from the list by prefixing them with @samp{-}.
229 Attributes [disallow-renewable]: requires-pre-auth,-disallow-renewable
231 Principal: me@@MY.REALM
233 Attributes: requires-pre-auth
243 YYYY-mm-dd
244 YYYY-mm-dd HH:MM:SS
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
289 (using the @kbd{--random-key} flag to get a random key) and then
293 kadmin> add --random-key host/my.host.name
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
316 kerberos-adm stream tcp nowait root /usr/heimdal/libexec/kadmind kadmind
319 You might need to add @samp{kerberos-adm} to your @file{/etc/services}
326 principal [priv1,priv2,...] [glob-pattern]
330 glob-pattern). When there is a match, the access rights of that line are
334 @samp{change-password} (or @samp{cpw} for short), @samp{delete},
339 If a @var{glob-pattern} is given on a line, it restricts the access
346 the realm @samp{E.KTH.SE}. @samp{mille/admin} is working at the
355 mille/admin@@E.KTH.SE change-password *@@E.KTH.SE
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 = @{
380 to guess them and to avoid off-line attacks (although
381 pre-authentication provides some defence against off-line attacks).
391 policies = external-check builtin:minimum-length modulename:policyname
398 @samp{policy_libraries}). All built-in policies can be qualified with
399 a module name of @samp{builtin} to unambiguously specify the built-in
402 The built-in policies are
406 @item external-check
415 new-password: @var{password}
426 error and exit with a non-zero error code.
428 @item minimum-length
434 @item character-class
436 The character-class password quality check reads the configuration
456 @file{lib/kadm5/check-cracklib.pl}.
462 @command{verify-password-quality} in @command{kadmin} program. The password
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
498 slave# ktutil get -p foo/admin hprop/`hostname`
504 the slaves. This principal should be added when running @kbd{kadmin -l
506 please add it with @kbd{kadmin -l add}.
516 This was just an hands-on example to make sure that everything was
526 @node Incremental propagation, Encryption types and salting, Slave Servers, Setting up a realm
539 Protocol-wise, all the slaves connect to the master and as a greeting
544 also a keep-alive protocol that makes sure all slaves are up and running.
547 slaves, the ipropd-master also listens on a status unix
550 ipropd-master to check for new version in the log file. As a fallback in
556 The program that runs on the master is @command{ipropd-master} and all
557 clients run @command{ipropd-slave}.
566 for some peculiar reason, you can use the @kbd{--port} option. This is
583 The next step is to start the @command{ipropd-master} process on the master
584 server. The @command{ipropd-master} listens on the UNIX domain socket
589 this signal. Then, start @command{ipropd-slave} on all the slaves:
592 master# /usr/heimdal/libexec/ipropd-master &
593 slave# /usr/heimdal/libexec/ipropd-slave master &
596 To manage the iprop log file you should use the @command{iprop-log}
599 …ryption types and salting, Credential cache server - KCM, Incremental propagation, Setting up a re…
609 Salting is used to make it harder to pre-calculate all possible
611 impossible to pre-calculate all keys. Salting is the process of mixing a
613 encryption type specific string-to-key function that will output the
620 (none at all) or the afs-salt (using the cell (realm in
631 @samp{[etype:]salt-type[:salt-string]}. @samp{etype} is the encryption
632 type (des-cbc-crc, arcfour-hmac-md5, aes256-cts-hmac-sha1-96),
633 @code{salt-type} is the type of salt (pw-salt or afs3-salt), and the
634 salt-string is the string that will be used as salt (remember that if
641 @item @code{v4} (or @code{des:pw-salt:})
647 @item @code{v5} (or @code{pw-salt})
649 @code{pw-salt} uses the default salt for each encryption type is
653 @item @code{afs3-salt}
655 @code{afs3-salt} is the salt that is used with Transarc kaserver. It's
660 @node Credential cache server - KCM, Cross realm, Encryption types and salting, Setting up a realm
661 @section Credential cache server - KCM
683 credentials. @command{klist -l} lists the credentials and the star
689 $ klist -l
698 $ kswitch -i
708 $ klist -l
721 -o GSSAPIAuthentication=yes \
722 -o GSSAPIKeyExchange=yes \
723 -o GSSAPIClientIdentity=lha@@KTH.SE \
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.
770 vr$ telnet -l lha hummel.it.su.se
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
819 if one of the transited-realms changed the order of the list. For 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
867 The order of the @code{PERMITTED-CROSS-REALMS} is not important when
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.
882 For client configuration, the order of @code{PERMITTED-CROSS-REALMS}
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
892 @code{PERMITTED-CROSS-REALMS} section), and then from there to
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:
948 @c kmumble transit-check client server transit-realms ...
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}:
982 _kerberos._tcp SRV 10 1 88 kerberos-1.example.com.
983 _kerberos._udp SRV 10 1 88 kerberos-1.example.com.
985 _kerberos-adm._tcp SRV 10 1 749 kerberos.example.com.
990 RFC-2782 (A DNS RR for specifying the location of services (DNS SRV)).
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
1033 @code{--with-openldap=/usr/local} (adjust according to where you have
1037 @file{kdc --builtin-hdb}, and checking that @samp{ldap:} is one entry
1041 see option --hdb-openldap-module to configure.
1044 Configure OpenLDAP with @kbd{--enable-local} to enable the local transport.
1047 Add the hdb schema to the LDAP server, it's included in the source-tree
1063 authz-regexp "gidNumber=.*\\\+uidNumber=0,cn=peercred,cn=external,cn=auth''
1068 The sasl-regexp is for mapping between the SASL/EXTERNAL and a user in
1078 security layer quality (ssf in cyrus-sasl lingo). So that requirement
1083 sasl-secprops minssf=0
1092 slapd -h "ldapi:/// ldap:///"
1097 schema definition syntax instead of the old UMich-style, V2 syntax.
1109 hdb-ldap-structural-object = inetOrgPerson
1117 hdb-ldap-structural-object is not necessary if you do not need Samba
1128 kdc# kadmin -l
1130 Realm max ticket life [unlimited]:
1131 Realm max renewable ticket life [unlimited]:
1139 Verifying password - lukeh@@EXAMPLE.COM's Password:
1147 kdc# ldapsearch -L -h localhost -D cn=manager \
1148 -w secret -b ou=KerberosPrincipals,dc=example,dc=com \
1172 @url{http://www.openldap.org/devel/cvsweb.cgi/contrib/slapd-modules/smbk5pwd/README?hideattic=1&sor…
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 …dentials to servers and programs, Setting up PK-INIT, Using LDAP to store the database, Setting up…
1212 host# ktutil -k /etc/krb5-service.keytab \
1213 get -p lha/admin@@EXAMPLE.ORG service-principal@@EXAMPLE.ORG
1218 @kbd{--keytab} mode. This will not ask for a password but instead fetch the
1222 service@@host$ kinit --cache=/var/run/service_krb5_cache \
1223 --keytab=/etc/krb5-service.keytab \
1224 service-principal@@EXAMPLE.ORG
1233 the credentials when the script-to-start-service exits.
1236 service@@host$ kinit --cache=/var/run/service_krb5_cache \
1237 --keytab=/etc/krb5-service.keytab \
1238 service-principal@@EXAMPLE.ORG \
1239 script-to-start-service argument1 argument2
1243 @node Setting up PK-INIT, Debugging Kerberos problems, Providing Kerberos credentials to servers an…
1244 @section Setting up PK-INIT
1246 PK-INIT leverages an existing PKI (public key infrastructure), using
1248 ticket-granting ticket).
1250 To use PK-INIT you must first have a PKI. If you don't have one, it is
1263 certificates and the format used in the id-pkinit-san OtherName
1271 id-pkkdcekuoid (1.3.6.1.5.2.3.5) set. Second, there must be a
1272 subjectAltName otherName using OID id-pkinit-san (1.3.6.1.5.2.2) in
1274 name of the TGS of the target realm. Also, if the certificate has a
1293 The client certificate may need to have a EKU id-pkekuoid
1307 @subsubsection Using KRB5PrincipalName in id-pkinit-san
1316 OtherName. The OID in the type is id-pkinit-san.
1319 id-pkinit-san OBJECT IDENTIFIER ::= @{ iso (1) org (3) dod (6)
1328 realm [0] Realm,
1333 where Realm and PrincipalName is defined by the Kerberos ASN.1
1378 FILE:certificate.pem,private-key.key,other-cert.pem,....
1384 soft-token, opensc, or muscle. The argument specifies a shared object
1391 PKCS11:shared-object.so
1414 $ kinit -C FILE:$HOME/.certs/lha.crt,$HOME/.certs/lha.key lha@@EXAMPLE.ORG
1427 $ kinit -C PKCS11:/usr/heimdal/lib/hx509.so lha@@EXAMPLE.ORG
1443 pkinit_anchors = FILE:/path/to/trust-anchors.pem
1459 enable-pkinit = yes
1461 pkinit_anchors = FILE:/path/to/trust-anchors.pem
1462 pkinit_pool = PKCS12:/path/to/useful-intermediate-certs.pfx
1463 pkinit_pool = FILE:/path/to/other-useful-intermediate-certs.pem
1469 @subsection Using pki-mapping file
1474 # cat /var/heimdal/pki-mapping
1489 You need to change --subject in the command below to something
1493 hxtool issue-certificate \
1494 --self-signed \
1495 --issue-ca \
1496 --generate-key=rsa \
1497 --subject="CN=CA,DC=test,DC=h5l,DC=se" \
1498 --lifetime=10years \
1499 --certificate="FILE:ca.pem"
1503 type ``pkinit-kdc'' and set the PK-INIT specifial SubjectAltName to the
1504 name of the krbtgt of the realm.
1506 You need to change --subject and --pk-init-principal in the command
1510 hxtool issue-certificate \
1511 --ca-certificate=FILE:ca.pem \
1512 --generate-key=rsa \
1513 --type="pkinit-kdc" \
1514 --pk-init-principal="krbtgt/TEST.H5L.SE@@TEST.H5L.SE" \
1515 --subject="uid=kdc,DC=test,DC=h5l,DC=se" \
1516 --certificate="FILE:kdc.pem"
1520 generate a certificate of type ``pkinit-client''. The client doesn't
1521 need to have the PK-INIT SubjectAltName set; you can have the Subject
1522 DN in the ACL file (pki-mapping) instead.
1524 You need to change --subject and --pk-init-principal in the command
1526 --pk-init-principal if you're going to use the ACL file instead.
1529 hxtool issue-certificate \
1530 --ca-certificate=FILE:ca.pem \
1531 --generate-key=rsa \
1532 --type="pkinit-client" \
1533 --pk-init-principal="lha@@TEST.H5L.SE" \
1534 --subject="uid=lha,DC=test,DC=h5l,DC=se" \
1535 --certificate="FILE:user.pem"
1558 creating client and KDC certificates, see the test-data generation
1559 script @file{lib/hx509/data/gen-req.sh} in the source-tree. The
1560 certicates it creates are used to test the PK-INIT functionality in
1561 @file{tests/kdc/check-kdc.in}.
1571 realm = EXP:0, GeneralString:MY.REALM
1586 openssl x509 -extensions user_certificate
1587 openssl ca -extensions user_certificate
1591 @c --- ms certificate
1605 @section Using PK-INIT with Windows
1609 Clients using a Windows KDC with PK-INIT need configuration since
1610 windows uses pre-standard format and this can't be autodetected.
1619 MY.MS.REALM = @{
1630 See Microsoft Knowledge Base Article - 281245 ``Guidelines for Enabling
1631 Smart Card Logon with Third-Party Certification Authorities'' for a
1638 2000 CA, you want to look at Microsoft Knowledge Base Article - 313274
1642 @node Debugging Kerberos problems, , Setting up PK-INIT, Setting up a realm
1651 libkrb5 = 0-/SYSLOG: