From Fedora Project Wiki

(Categories)
No edit summary
 
(4 intermediate revisions by one other user not shown)
Line 1: Line 1:
{{QA/Test_Case
{{QA/Test_Case
|description= Demonstrate that MIT Kerberos 1.11 reverts to default behavior (rather than categorically rejecting the authentication) in the scenario where:
|description=Demonstrate that MIT Kerberos 1.11 reverts to default behavior (rather than categorically rejecting the authentication) in the scenario where:
* The client does not present a domain name to authenticate against.
* The client does not present a domain name to authenticate against.
* Reverse DNS is enabled in /etc/krb5.conf
* Reverse DNS is enabled in /etc/krb5.conf
* The server does not have a PTR record on the DNS server.
* The server does not have a PTR record on the DNS server.
|setup=
|setup=
# [[Features/ActiveDirectory/TestBed|Verify that your ActiveDirectory domain access works]]. If you don't have an Active Directory domain, you can [[Features/ActiveDirectory/TestBed|set one up]].
# Perform [[QA:Testcase_kerberos_setup|prerequisite setup]] before you run this test.
# You need a domain account, either a user or administrator. It's useful to test with both.
# You need a realm user or administrator account.
# '''Your machine must have a configured host name. Do not proceed if you host name is <code>localhost</code> or similar.'''
# Make sure you have krb5-workstation-1.11 or later installed. You also need openldap-clients in order to use the 'ldapwhoami' command.
#: <pre>$ hostname</pre>
# Make note of the the DNS name for a domain controller on your domain
# Make sure you have krb5-workstation-1.11 or later installed.
#: <pre>$ host -t SRV _kerberos._udp.domain.example.com</pre>
# Make note of the IP address of the domain controller you chose above:
#: <pre>$ host dc.example.com</pre>
# Now verify that the reverse DNS record for that IP address '''does not exist''' or '''does not match''' that of your domain controller:
#: <pre>$ host -t PTR X.X.X.X</pre>
#: If it does match, then either find a way to break the mapping (if you set it up yourself) or skip this test.
# Verify that <code>/etc/krb5.conf</code> exists, and contains this line, in the <code>[libdefaults]</code> section:
#: <pre>rdns = false</pre>
#: If the file does not exist, reinstall krb5-libs:
#: <pre>$ sudo yum reinstall krb5-libs</pre>
|actions=
|actions=
# Use the DNS Manager console on the Active Directory server to remove the PTR record that establishes the ip-to-hostname mapping for the server.
# In your client's /etc/krb5.conf, enable the use of reverse dns by setting the "rdns" attribute to "true"
# Use your Active Directory domain user account to authenticate to the Active Directory server using kinit without a realm name.
# Use your Active Directory domain user account to authenticate to the Active Directory server using kinit without a realm name.
#: <pre>$ kinit user</pre>
#: <pre>$ kinit user@AD.EXAMPLE.COM</pre>
#: <pre>Password for user@AD.EXAMPLE.COM</pre>
#* Type your domain account password
#* Make sure that you capitalize the domain name.
#* Make sure that you capitalize the domain name.
#* If the above fails with 'Preauthentication failed' then you probably typed the wrong password.
#* If the above fails with 'Preauthentication failed' then you probably typed the wrong password.
#* There should be no output from this command.
# Now do an LDAP search against your domain controller
#: <pre>$ ldapwhoami -H ldap://dc.example.com -Y GSSAPI</pre>
#: You must use the exact domain controller name (as discovered in the above stages, in order for this to work).
|results=
|results=
# Check that you have an appropriate entry in your credentials cache using the klist command.
# The <code>ldapwhoami</code> command should output your user name on the last line, and should not fail.
#:<pre>$ klist</pre>
#:<pre>$ klist</pre>
#* You should see a line that has a service principal named "krbtgt/AD.EXAMPLE.COM@AD.EXAMPLE.COM"
#* You should see a line that contains the domain controller host name
}}
}}


== Troubleshooting ==
== Troubleshooting ==
TBD
 
If you want to file a bug related to this issue, run the command with the the <code>KRB5_TRACE=/dev/stderr</code> environment variable, like this:
 
<pre>$ KRB5_TRACE=/dev/stderr kinit user@AD.EXAMPLE.COM</pre>


[[Category:Active_Directory_Test_Cases]] [[Category:Kerberos_Test_Cases]]
[[Category:Active_Directory_Test_Cases]] [[Category:Kerberos_Test_Cases]]

Latest revision as of 11:09, 9 May 2013

Description

Demonstrate that MIT Kerberos 1.11 reverts to default behavior (rather than categorically rejecting the authentication) in the scenario where:

  • The client does not present a domain name to authenticate against.
  • Reverse DNS is enabled in /etc/krb5.conf
  • The server does not have a PTR record on the DNS server.

Setup

  1. Perform prerequisite setup before you run this test.
  2. You need a realm user or administrator account.
  3. Make sure you have krb5-workstation-1.11 or later installed. You also need openldap-clients in order to use the 'ldapwhoami' command.
  4. Make note of the the DNS name for a domain controller on your domain
    $ host -t SRV _kerberos._udp.domain.example.com
  5. Make note of the IP address of the domain controller you chose above:
    $ host dc.example.com
  6. Now verify that the reverse DNS record for that IP address does not exist or does not match that of your domain controller:
    $ host -t PTR X.X.X.X
    If it does match, then either find a way to break the mapping (if you set it up yourself) or skip this test.
  7. Verify that /etc/krb5.conf exists, and contains this line, in the [libdefaults] section:
    rdns = false
    If the file does not exist, reinstall krb5-libs:
    $ sudo yum reinstall krb5-libs

How to test

  1. Use your Active Directory domain user account to authenticate to the Active Directory server using kinit without a realm name.
    $ kinit user@AD.EXAMPLE.COM
    • Type your domain account password
    • Make sure that you capitalize the domain name.
    • If the above fails with 'Preauthentication failed' then you probably typed the wrong password.
  2. Now do an LDAP search against your domain controller
    $ ldapwhoami -H ldap://dc.example.com -Y GSSAPI
    You must use the exact domain controller name (as discovered in the above stages, in order for this to work).

Expected Results

  1. The ldapwhoami command should output your user name on the last line, and should not fail.
    $ klist
    • You should see a line that contains the domain controller host name



Troubleshooting

If you want to file a bug related to this issue, run the command with the the KRB5_TRACE=/dev/stderr environment variable, like this:

$ KRB5_TRACE=/dev/stderr kinit user@AD.EXAMPLE.COM