From Fedora Project Wiki

(Add known issues)
No edit summary
 
(5 intermediate revisions by one other user not shown)
Line 2: Line 2:
|description=Permit a domain account to log in locally, and then test that login.
|description=Permit a domain account to log in locally, and then test that login.
|setup=
|setup=
# Due to [https://bugzilla.redhat.com/show_bug.cgi?id=867473 this bug] with [http://lists.fedoraproject.org/pipermail/devel/2012-October/172688.html discussion here], you need to have <code>sss</code> in your <code>/etc/nsswitch.conf</code> when you last booted you system. To do so run this:
#: <pre>$ sudo authconfig --update --enablesssd; sudo shutdown -r now</pre>
# If you are linked to your Active Directory domain via VPN, then this Test case will not work.
# If you are linked to your Active Directory domain via VPN, then this Test case will not work.
# [[Features/ActiveDirectory/TestBed|Verify that your Active Directory domain access works]]. If you don't have an Active Directory domain, you can [[Features/ActiveDirectory/TestBed|set one up]].
# Make sure you have other required software:
#* realmd 0.14.0 or later
# Verify that your [[QA:Testcase_Active_Directory_Setup|Active Directory domain access works, or set a domain up]].
# Run through the [[QA:Testcase_Active_Directory_realmd_join_sssd|test case to join the domain]].
# Run through the [[QA:Testcase_Active_Directory_realmd_join_sssd|test case to join the domain]].
# Verify that you are joined to the domain with the following command
# Verify that you are joined to the domain with the following command
Line 11: Line 11:
#: Make sure you have a <code>configured: kerberos-membership</code> line in the output.
#: Make sure you have a <code>configured: kerberos-membership</code> line in the output.
#: Note the <code>login-formats:</code> line.
#: Note the <code>login-formats:</code> line.
# Check that you cannot resolve domain accounts on the local computer.  
# Check that you can resolve domain accounts on the local computer.  
#: Use the <code>login-formats</code> you saw above, to build a remote user name. It will be in the form of <code>DOMAIN\User</code>, where DOMAIN is the first part of your full Active Directory domain name.
#: Use the <code>login-formats</code> you saw above, to build a remote user name. It will be in the form of <code>DOMAIN\User</code>, where DOMAIN is the first part of your full Active Directory domain name.
#: <pre>$ getent passwd 'AD\User'</pre>
#: <pre>$ getent passwd 'AD\User'</pre>
Line 29: Line 29:
#: On a Live CD if you get automatically logged in again, go to ''User Accounts'' and turn off Auto Login for the live cd user.
#: On a Live CD if you get automatically logged in again, go to ''User Accounts'' and turn off Auto Login for the live cd user.
# Choose the ''Not Listed?'' option.
# Choose the ''Not Listed?'' option.
#: Verify that you can see the short name listed with a hint as to how to log in.
# Type <code>DOMAIN\User</code> in the box.
# Type <code>DOMAIN\User</code> in the box.
#: The case of the domain and user should not matter, but they are separated by a backslash.
#: The case of the domain and user should not matter, but they are separated by a backslash.
Line 46: Line 45:
If the above explodes, try to log in from a VT console, and see if there is any interesting output there.
If the above explodes, try to log in from a VT console, and see if there is any interesting output there.


If you can log into a VT, but cannot log into GNOME, then you may have run into [https://bugzilla.redhat.com/show_bug.cgi?id=867473 this bug]. See the top of the ''Setup'' part of this test case for a solution.
If you are connected to your domain controller via VPN, the above test case will not work.
 
If login not works, you can try to use workaround. Open the /etc/sssd/sssd.conf file and put the following into the [domain/$DOMNAME] section:


If you are connected to your domain controller via VPN, the above test case will not work.
<pre>krb5_use_enterprise_principal=False</pre>
<pre>service sssd restart</pre>


'''Known Issue [[https://bugzilla.redhat.com/show_bug.cgi?id=867874 Group Names]]:''' Group names for the logged in user are not resolved correctly
Try login again.


'''Known Issue [[https://bugzilla.redhat.com/show_bug.cgi?id=867873 Selinux]]:''' You need to turn off selinux to complete the permit action. Please do:
You can use pamtester to play with authentication:


<pre>
<pre>$ sudo yum install pamtester
$ sudo setenforce 0
$ pamtester system-auth 'DOMAIN\User' authenticate
Password: xxxx
</pre>
</pre>


Please file the all realmd AVC's at this bug: https://bugzilla.redhat.com/show_bug.cgi?id=867873
You can increase the sssd debug log level, and check log files:


<pre>
<pre>$ sudo sss_debuglevel 0x00F0
$ sudo grep realmd /var/log/audit/audit.log
... do the thing here ...
</pre>
$ sudo less /var/log/sssd/sssd_xxx.log</pre>


[[Category:Active_Directory_Test_Cases]]
[[Category:Active_Directory_Test_Cases]] [[Category:Realmd_Test_Cases]]

Latest revision as of 10:35, 9 May 2013

Description

Permit a domain account to log in locally, and then test that login.

Setup

  1. If you are linked to your Active Directory domain via VPN, then this Test case will not work.
  2. Make sure you have other required software:
    • realmd 0.14.0 or later
  3. Verify that your Active Directory domain access works, or set a domain up.
  4. Run through the test case to join the domain.
  5. Verify that you are joined to the domain with the following command 
    $ realm list
    Make sure you have a configured: kerberos-membership line in the output.
    Note the login-formats: line.
  6. Check that you can resolve domain accounts on the local computer.
    Use the login-formats you saw above, to build a remote user name. It will be in the form of DOMAIN\User, where DOMAIN is the first part of your full Active Directory domain name.
    $ getent passwd 'AD\User'

How to test

  1. Perform the permit command. 
    $ realm permit --realm=ad.example.com 'AD\User'
    You will be prompted for Policy Kit authorization.
    You will not be prompted for a password.
    This should proceed quickly, not take more that 10 seconds.
    On a successful permit there will be no output.
  2. The user should show up here: 
    $ realm list
    Look at the permitted-logins: line.
    You should also see login-policy: allow-permitted-logins.
  3. Go to GDM by logging out, or by Switch User from the user menu.
    On a Live CD if you get automatically logged in again, go to User Accounts and turn off Auto Login for the live cd user.
  4. Choose the Not Listed? option.
  5. Type DOMAIN\User in the box.
    The case of the domain and user should not matter, but they are separated by a backslash.
    The domain part is the part of your Active Directory domain prior to the first dot.
  6. Type the user domain password, and press enter.

Expected Results

  1. You should be logged into the Fedora desktop.
  2. Open a terminal, and type: 
    $ id
    Look at the output to verify that you are logged in as a domain user.



Troubleshooting

If the above explodes, try to log in from a VT console, and see if there is any interesting output there.

If you are connected to your domain controller via VPN, the above test case will not work.

If login not works, you can try to use workaround. Open the /etc/sssd/sssd.conf file and put the following into the [domain/$DOMNAME] section: 

krb5_use_enterprise_principal=False
service sssd restart

Try login again.

You can use pamtester to play with authentication: 

$ sudo yum install pamtester
$ pamtester system-auth 'DOMAIN\User' authenticate
Password: xxxx

You can increase the sssd debug log level, and check log files: 

$ sudo sss_debuglevel 0x00F0
... do the thing here ...
$ sudo less /var/log/sssd/sssd_xxx.log
Retrieved from "https://fedoraproject.org/w/index.php?title=QA:Testcase_realmd_login&oldid=336346"