Features/ActiveDirectory/TestingRealmd

From FedoraProject

< Features | ActiveDirectory(Difference between revisions)
Jump to: navigation, search
(Test using domain without krb5.conf)
(Make this a stub page referring to test cases)
 
(2 intermediate revisions by one user not shown)
Line 9: Line 9:
 
Report bugs here: https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora&component=realmd
 
Report bugs here: https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora&component=realmd
  
== Preparation ==
+
== Test Day ==
  
In order to test realmd with Active Directory, you need to have realmd installed, and an Active Directory domain to test against: [[Features/ActiveDirectory/TestingRealmd/Preparation|Preparation steps]]
+
There's a test day going on which you can see here:
  
== Test using domain without krb5.conf ==
+
[[Test_Day:2012-10-18_Active_Directory|2012-10-18_Active_Directory]]
  
Work has been done to make krb5.conf configurationless, and unbreak the default <code>/etc/krb5.conf</code> that was distributed with Fedora 17 and earlier.
+
The various test cases can be seen here:
  
Move <code>/etc/krb5.conf</code> away.
+
[[:Category:Active_Directory_Test_Cases]]
 
+
<pre>
+
$ sudo mv /etc/krb5.conf /etc/krb5.conf.bak
+
</pre>
+
 
+
If you wish to test with a default neutral <code>/etc/krb5.conf</code> file, use the following file, as included in the <code>krb5-libs</code> package:
+
 
+
<pre>
+
[logging]
+
default = FILE:/var/log/krb5libs.log
+
kdc = FILE:/var/log/krb5kdc.log
+
admin_server = FILE:/var/log/kadmind.log
+
 
+
[libdefaults]
+
dns_lookup_realm = false
+
ticket_lifetime = 24h
+
renew_lifetime = 7d
+
forwardable = true
+
# default_realm = EXAMPLE.COM
+
 
+
[realms]
+
# EXAMPLE.COM = {
+
#  kdc = kerberos.example.com
+
#  admin_server = kerberos.example.com
+
# }
+
 
+
[domain_realm]
+
# .example.com = EXAMPLE.COM
+
# example.com = EXAMPLE.COM
+
</pre>
+
 
+
But again, it is not required to have a <code>/etc/krb5.conf</code> at all.
+
 
+
Now do a <code>kinit</code> against your Active Directory domain. Yes it's vital that you use the fully capitalized form of the domain name:
+
 
+
<pre>
+
$ kinit Administrator@AD.EXAMPLE.COM
+
Password for Administrator@AD.EXAMPLE.COM:  
+
$ klist -e
+
Ticket cache: DIR::/run/user/1000/krb5cc_...
+
Default principal: Administrator@AD.EXAMPLE.COM
+
 
+
Valid starting    Expires            Service principal
+
10/15/12 00:52:34  10/15/12 10:52:34  krbtgt/AD.EXAMPLE.COM@AD.EXAMPLE.COM
+
        renew until 10/16/12 00:52:39, Etype (skey, tkt): aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96
+
</pre>
+
 
+
You should see kerberos tickets listed.
+
 
+
Possible non-systemic problems:
+
* Make sure the domain is capitalized as above. This is the kerberos realm name for the Active Directory domain.
+
* Make sure that the domain can be resolved via DNS: <code>$ host -t SRV _kerberos._udp.ad.example.com</code>
+
 
+
== Test realmd Discovery ==
+
 
+
realmd discovers domains and what kind of domain they are. To test this use the <code>realm</code> command to drive realmd.
+
 
+
Against an Active Directory domain the output should look like this:
+
 
+
<pre>
+
$ realm discover --verbose ad.example.com
+
* Searching for kerberos SRV records for domain: _kerberos._udp.ad.example.com
+
* Searching for MSDCS SRV records on domain: _kerberos._tcp.dc._msdcs.ad.example.com
+
* dc.ad.example.com:88
+
* Found kerberos DNS records for: ad.example.com
+
* Found AD style DNS records for: ad.example.com
+
* Successfully discovered: ad.example.com
+
AD.EXAMPLE.COM
+
  configured: no
+
  type: active-directory
+
  realm-name: AD.EXAMPLE.COM
+
  domain-name: ad.example.com
+
</pre>
+
 
+
Against an IPA domain the output should look something like this:
+
<pre>
+
$ realm --verbose discover ipa.example.com
+
* Searching for kerberos SRV records for domain: _kerberos._udp.ipa.example.com
+
* Searching for MSDCS SRV records on domain: _kerberos._tcp.dc._msdcs.ipa.example.com
+
* dc.ipa.example.com:88
+
* Trying to retrieve IPA certificate from dc.ipa.example.com
+
! Couldn't read certificate via HTTP: No PEM-encoded certificate found
+
! Couldn't discover IPA KDC: No PEM-encoded certificate found
+
* Found kerberos DNS records for: ipa.example.com
+
* Successfully discovered: ipa.example.com
+
NULLROUTE.EU.ORG
+
  configured: no
+
  type: freeipa
+
  realm-name: IPA.EXAMPLE.COM
+
  domain-name: ipa.example.com
+
</pre>
+
 
+
Against a generic kerberos domain, such as redhat.com, or nullroute.eu.org, it should look something like this:
+
 
+
<pre>
+
$ realm discover --verbose nullroute.eu.org
+
* Searching for kerberos SRV records for domain: _kerberos._udp.nullroute.eu.org
+
* Searching for MSDCS SRV records on domain: _kerberos._tcp.dc._msdcs.nullroute.eu.org
+
* virgule.cluenet.org:88 panther.nathan7.eu:88
+
* Trying to retrieve IPA certificate from virgule.cluenet.org
+
* Trying to retrieve IPA certificate from panther.nathan7.eu
+
! Couldn't read certificate via HTTP: No PEM-encoded certificate found
+
! Couldn't discover IPA KDC: No PEM-encoded certificate found
+
* Found kerberos DNS records for: nullroute.eu.org
+
* Successfully discovered: nullroute.eu.org
+
NULLROUTE.EU.ORG
+
  configured: no
+
  type: kerberos
+
  realm-name: NULLROUTE.EU.ORG
+
  domain-name: nullroute.eu.org
+
</pre>
+
 
+
== Join an Active Directory domain using sssd ==
+
 
+
Join the current machine to an Active Directory domain using sssd as an AD client. Domain accounts are usable on the local machine once this is done.
+
 
+
<pre>
+
$ realm join ad.example.com
+
Password for Administrator:
+
</pre>
+
 
+
You can use the <code>--user</code> argument to specify a different user other than Administrator. If you use the <code>--verbose</code> command you can see the details of what's going on:
+
 
+
<pre>
+
$ realm join --verbose ad.example.com
+
* Searching for kerberos SRV records for domain: _kerberos._udp.ad.example.com
+
* Searching for MSDCS SRV records on domain: _kerberos._tcp.dc._msdcs.ad.example.com
+
* dc.ad.example.com:88
+
* Found kerberos DNS records for: ad.example.com
+
* Found AD style DNS records for: ad.example.com
+
* Successfully discovered: ad.example.com
+
* Required files present: /usr/sbin/sssd, /usr/sbin/adcli
+
* LANG=C /usr/sbin/adcli join --verbose --show-details --domain AD.EXAMPLE.COM --login-type computer --no-password
+
! Couldn't find qualified domain name, proceeding with local host name instead: local-machine.example.com: Name or service not known
+
* Using domain name: AD.EXAMPLE.COM
+
* Calculated computer account name from fqdn: AD.EXAMPLE.COM
+
* Calculated domain realm from name: AD.EXAMPLE.COM
+
* Resolved LDAP urls from SRV record: _ldap._tcp.AD.EXAMPLE.COM: ldap://dc.ad.example.com:389
+
! Couldn't authenticate as machine account: LOCAL-MACHINE: Client not found in Kerberos database
+
adcli: couldn't connect to AD.EXAMPLE.COM domain: Couldn't authenticate as machine account: LOCAL-MACHINE: Client not found in Kerberos database
+
! Insufficient permissions to join the domain
+
Password for Administrator:
+
* Required files present: /usr/sbin/sssd, /usr/bin/net
+
* LANG=C /usr/bin/net -s /usr/lib64/realmd/net-ads-smb.conf conf setparm global realm AD.EXAMPLE.COM
+
* LANG=C /usr/bin/net -s /usr/lib64/realmd/net-ads-smb.conf -U Administrator ads join AD.EXAMPLE.COM
+
Enter Administrator's password:
+
Using short domain name -- AD
+
Joined 'LOCAL-MACHINE' to realm 'ad.example.com'
+
* LANG=C /usr/bin/net -s /usr/lib64/realmd/net-ads-smb.conf -U Administrator ads keytab create
+
Enter Administrator's password:
+
* LANG=C /usr/bin/net -s /usr/lib64/realmd/net-ads-smb.conf conf list
+
[global]
+
workgroup = AD
+
security = ads
+
realm = ad.example.com
+
* /usr/bin/systemctl enable sssd.service
+
* /usr/bin/systemctl restart sssd.service
+
* /usr/sbin/authconfig --update --enablesssd --enablesssdauth
+
* Successfully enrolled machine in realm
+
</pre>
+
 
+
At this point you should be able to resolve domain accounts locally:
+
 
+
<pre>
+
$ getent passwd 'AD\Administrator'
+
AD\administrator:*:1344600500:1344600513:Administrator:/home/AD/administrator:/bin/bash
+
</pre>
+
 
+
You can see that you're joined to the domain with the following command:
+
 
+
<pre>
+
$ realm list
+
</pre>
+
 
+
Possible problems:
+
* Anaconda in Fedora 18 fails to set up a host name. Make sure this is set in advance.
+
* Clock skew is too great. Work was done to make the clock skew not matter, however this did not make it into Fedora 18. In the interim, make sure your Active Directory domain and local machine are both using NTP. Make sure the timezone on both machines are correct.
+
 
+
== Leave an Active Directory domain ==
+
 
+
Now that you're joined to an Active Directory domain, you can leave it as well.
+
 
+
<pre>
+
$ realm leave
+
Password for Administrator:
+
</pre>
+
 
+
If you want to see details of what's going on, or specify the domain explicitly you can do it like this:
+
 
+
<pre>
+
$ realm leave --verbose ad.example.com
+
Password for Administrator:
+
* LANG=C /usr/bin/net -s /usr/lib64/realmd/net-ads-smb.conf -U Administrator ads keytab flush
+
Enter Administrator's password:
+
* LANG=C /usr/bin/net -s /usr/lib64/realmd/net-ads-smb.conf -U Administrator ads leave
+
Enter Administrator's password:
+
Deleted account for 'LOCAL-MACHINE' in realm 'AD.EXAMPLE.COM'
+
* /usr/bin/systemctl disable sssd.service
+
rm '/etc/systemd/system/multi-user.target.wants/sssd.service'
+
* /usr/bin/systemctl stop sssd.service
+
* Successfully unenrolled machine from realm
+
</pre>
+
 
+
You can see that you're not joined to the domain with the following command:
+
 
+
<pre>
+
$ realm list
+
</pre>
+
 
+
== Join an Active Directory domain using winbind ==
+
 
+
Join the current machine to an Active Directory domain using winbind as an AD client. Domain accounts are usable on the local machine once this is done.
+
 
+
<pre>
+
$ realm join --verbose --client-software=winbind ad.example.com
+
Password for Administrator:
+
</pre>
+
 
+
You can use the <code>--user</code> argument to specify a different user other than Administrator. If you use the <code>--verbose</code> command you can see the details of what's going on:
+
 
+
<pre>
+
$ realm join --verbose --client-software=winbind ad.example.com
+
ad.example.com
+
* Searching for kerberos SRV records for domain: _kerberos._udp.ad.example.com
+
* Searching for MSDCS SRV records on domain: _kerberos._tcp.dc._msdcs.ad.example.com
+
* dc.ad.example.com:88
+
* Found kerberos DNS records for: ad.example.com
+
* Found AD style DNS records for: ad.example.com
+
* Successfully discovered: ad.example.com
+
Password for Administrator:
+
* Couldn't find file: /usr/sbin/winbindd
+
* Required files not present, installing: /usr/sbin/winbindd, /usr/bin/wbinfo, /usr/bin/net
+
* Installing: samba4-winbind, samba4-winbind-clients, samba4-common
+
* LANG=C /usr/bin/net -s /usr/lib64/realmd/net-ads-smb.conf conf setparm global realm AD.EXAMPLE.COM
+
* LANG=C /usr/bin/net -s /usr/lib64/realmd/net-ads-smb.conf -U Administrator ads join AD.EXAMPLE.COM
+
Enter Administrator's password:
+
Using short domain name -- AD
+
Joined 'STEF-REDHAT' to realm 'ad.example.com'
+
* LANG=C /usr/bin/net -s /usr/lib64/realmd/net-ads-smb.conf -U Administrator ads keytab create
+
Enter Administrator's password:
+
* LANG=C /usr/bin/net -s /usr/lib64/realmd/net-ads-smb.conf conf list
+
[global]
+
workgroup = AD
+
security = ads
+
realm = ad.example.com
+
 
+
* /usr/bin/systemctl enable winbind.service
+
ln -s '/usr/lib/systemd/system/winbind.service' '/etc/systemd/system/multi-user.target.wants/winbind.service'
+
* /usr/bin/systemctl restart winbind.service
+
* /usr/sbin/authconfig --update --enablewinbind --enablewinbindauth
+
* Successfully enrolled machine in realm
+
</pre>
+
 
+
At this point you should be able to resolve domain accounts locally:
+
 
+
<pre>
+
$ getent passwd 'AD\Administrator'
+
AD\administrator:*:10000:10000:Administrator:/home/AD/administrator:/bin/bash
+
</pre>
+
 
+
You can see that you're joined to the domain with the following command:
+
 
+
<pre>
+
$ realm list
+
</pre>
+
 
+
Possible problems:
+
* Anaconda in Fedora 18 fails to set up a host name. Make sure this is set in advance.
+
* Clock skew is too great. Work was done to make the clock skew not matter, however this did not make it into Fedora 18. In the interim, make sure your Active Directory domain and local machine are both using NTP. Make sure the timezone on both machines are correct.
+
 
+
== Permit logins on the Active Directory domain ==
+
 
+
After joining a domain, realmd does not automatically logins to the local machine for domain accounts.
+
 
+
To permit any login use:
+
 
+
<pre>
+
$ realm permit --realm ad.example.com --all
+
</pre>
+
 
+
To permit specific logins, use:
+
 
+
<pre>
+
$ realm permit --realm ad.example.com AD\Administrator AD\OtherUser
+
</pre>
+
 
+
To test logins you can use the <code>pamtester</code> tool, available in the Fedora software repository.
+
 
+
<pre>
+
$ pamtester login 'AD\Administrator' authenticate
+
Password:
+
pamtester: successfully authenticated
+
</pre>
+
 
+
== Use GNOME Control Center with Active Directory ==
+
 
+
You can use GNOME Control Center to join an Active Directory domain, and permit logins by users. Only those users specifically added are permitted to log in.
+
 
+
* Run <code>gnome-control-center</code>
+
* Choose the ''User Accounts'' panel.
+
* Click the ''Unlock'' button.
+
* Click the add [+] button in the lower left.
+
* Choose the ''Enterprise login'' pane.
+
* Fill in the domain, domain user, and domain password for the account.
+
* Click on ''Add''
+
 
+
If you are not yet joined to the domain, then a join will occur, with likely prompting for administrative credentials.
+
 
+
You should see diagnostic output on the terminal that you ran <code>gnome-control-center</code> from.
+
 
+
== Perform a passwordless join ==
+
 
+
In order to perform a passwordless join, you create a machine account in the domain, and reset its password.
+
 
+
You can use the ''Active Directory Users and Computers'' tool on Windows Server to do this. Open the directory, right click on ''Computers'' and choose ''New > Computer'' from the menu that pops up. Fill in the name, the same as your local machine. Once the computer is created, go into ''Computers'' right click on it and ''Reset Account''.
+
 
+
You can also use the <code>adcli</code> tool to create a reset computer account:
+
 
+
<pre>
+
adcli preset --verbose --domain ad.example.com local-machine
+
</pre>
+
 
+
Once you have a preset computer account, you can perform the realmd join as usual, and not be prompted for credentials:
+
 
+
<pre>
+
$ realm join ad.example.com
+
</pre>
+
 
+
== Perform a one time password join ==
+
 
+
In a one time password join, a computer account is precereated in the domain, ready for a join to be done with a specific password that can only be used once on that computer account.
+
 
+
You can use the <code>adcli</code> tool to create a computer account ready for a one time password join:
+
 
+
<pre>
+
adcli preset --verbose --domain ad.example.com --one-time-password=MyPassword local-machine
+
</pre>
+
 
+
Once you have a preset computer account, you can perform the realmd join as usual, and not be prompted for credentials:
+
 
+
<pre>
+
$ realm join --one-time-password=MyPassword ad.example.com
+
</pre>
+

Latest revision as of 13:52, 17 October 2012

[edit] Testing Fedora 18 Active Directory Integration

realmd is a DBus based management service that configures membership of realms/domains on the local machine.

realmd documentation: http://www.freedesktop.org/software/realmd/docs/index.html

In addition many bugs and brittleness have been fixed in krb5. This documentation involves some testing of that as well.

Report bugs here: https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora&component=realmd

[edit] Test Day

There's a test day going on which you can see here:

2012-10-18_Active_Directory

The various test cases can be seen here:

Category:Active_Directory_Test_Cases