ACC SHELL
<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>Chapter 5. Active Directory Support</title><link rel="stylesheet" href="susebooks.css" type="text/css"><meta name="generator" content="DocBook XSL Stylesheets V1.75.2"><link rel="home" href="index.html" title="Documentation"><link rel="up" href="part.auth.html" title="Part I. Authentication"><link rel="prev" href="cha.security.ldap.html" title="Chapter 4. LDAP—A Directory Service"><link rel="next" href="cha.security.kerberos.html" title="Chapter 6. Network Authentication with Kerberos"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table width="100%" summary="Navigation header" border="0" class="bctable"><tr><td width="80%"><div class="breadcrumbs"><p><a href="index.html"> Documentation</a><span class="breadcrumbs-sep"> > </span><a href="book.security.html">Security Guide</a><span class="breadcrumbs-sep"> > </span><a href="part.auth.html">Authentication</a><span class="breadcrumbs-sep"> > </span><strong><a accesskey="p" title="Chapter 4. LDAP—A Directory Service" href="cha.security.ldap.html"><span>◀</span></a> <a accesskey="n" title="Chapter 6. Network Authentication with Kerberos" href="cha.security.kerberos.html"><span>▶</span></a></strong></p></div></td></tr></table></div><div class="chapter" title="Chapter 5. Active Directory Support"><div class="titlepage"><div><div><h2 class="title"><a name="cha.security.ad"></a>Chapter 5. Active Directory Support<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#cha.security.ad">¶</a></span></h2></div></div></div><div class="toc"><p><b>Contents</b></p><dl><dt><span class="sect1"><a href="cha.security.ad.html#sec.security.ad.integrate">5.1. Integrating Linux and AD Environments</a></span></dt><dt><span class="sect1"><a href="cha.security.ad.html#sec.security.ad.background">5.2. Background Information for Linux AD Support</a></span></dt><dt><span class="sect1"><a href="cha.security.ad.html#sec.security.ad.config">5.3. Configuring a Linux Client for Active Directory</a></span></dt><dt><span class="sect1"><a href="cha.security.ad.html#sec.security.ad.login">5.4. Logging In to an AD Domain</a></span></dt><dt><span class="sect1"><a href="cha.security.ad.html#sec.security.ad.passwd">5.5. Changing Passwords</a></span></dt></dl></div><p>
Active Directory* (AD) is a directory-service based on LDAP, Kerberos, and
other services that is used by Microsoft Windows to manage resources,
services, and people. In an MS Windows network, AD provides information
about these objects, restricts access to them, and enforces policies.
openSUSE® lets you join existing AD domains and integrate your
Linux machine into a Windows environment.
</p><div class="sect1" title="5.1. Integrating Linux and AD Environments"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="sec.security.ad.integrate"></a>5.1. Integrating Linux and AD Environments<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.security.ad.integrate">¶</a></span></h2></div></div></div><p>
With a Linux client (configured as an Active Directory client) that is
joined to an existing Active Directory domain, benefit from various
features not available on a pure openSUSE Linux client:
</p><div class="variablelist"><dl><dt><span class="term">Browsing Shared Files and Folders with SMB</span></dt><dd><p>
Both Nautilus (the GNOME file manager) and Konqueror (its KDE
counterpart) support browsing shared resources through SMB.
</p></dd><dt><span class="term">Sharing Files and Folders with SMB</span></dt><dd><p>
Both Nautilus (the GNOME file manager) and Konqueror (its KDE
counterpart) support sharing folders and files as in Windows.
</p></dd><dt><span class="term">Accessing and Manipulating User Data on the Windows Server</span></dt><dd><p>
Through Nautilus and Konqueror, users are able to access their Windows
user data and can edit, create, and delete files and folders on the
Windows server. Users can access their data without having to enter
their password multiple times.
</p></dd><dt><span class="term">Offline Authentication</span></dt><dd><p>
Users are able to log in and access their local data on the Linux
machine even if they are offline or the AD server is unavailable for
other reasons.
</p></dd><dt><span class="term">Windows Password Change</span></dt><dd><p>
This port of AD support in Linux enforces corporate password policies
stored in Active Directory. The display managers and console support
password change messages and accept your input. You can even use the
Linux <span class="command"><strong>passwd</strong></span> command to set Windows passwords.
</p></dd><dt><span class="term">Single-Sign-On through Kerberized Applications</span></dt><dd><p>
Many applications of both desktops are Kerberos-enabled
(<span class="emphasis"><em>kerberized</em></span>), which means they can transparently
handle authentication for the user without the need for password
reentry at Web servers, proxies, groupware applications, or other
locations.
</p></dd></dl></div><p>
A brief technical background for most of these features is given in the
following section. <span>For directions for file and
printer sharing, refer to the GNOME User Guide (↑GNOME User Guide) and
the KDE User Guide (↑KDE User Guide), where you can learn more about AD
enablement in the GNOME and KDE application worlds.</span>
</p></div><div class="sect1" title="5.2. Background Information for Linux AD Support"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="sec.security.ad.background"></a>5.2. Background Information for Linux AD Support<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.security.ad.background">¶</a></span></h2></div></div></div><p>
Many system components need to interact flawlessly in order to integrate
a Linux client into an existing Windows Active Directory domain.
<a class="xref" href="cha.security.ad.html#fig.ad.schema" title="Figure 5.1. Active Directory Authentication Schema">Figure 5.1, “Active Directory Authentication Schema”</a> highlights the most prominent ones. The
following sections focus on the underlying processes of the key events in
AD server and client interaction.
</p><div class="figure"><a name="fig.ad.schema"></a><p class="title"><b>Figure 5.1. Active Directory Authentication Schema</b><span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#fig.ad.schema">¶</a></span></p><div class="figure-contents"><div class="mediaobject"><table border="0" summary="manufactured viewport for HTML img" cellspacing="0" cellpadding="0" width="75%"><tr><td><img src="images/sled10_ad_schema.png" width="100%" alt="Active Directory Authentication Schema"></td></tr></table></div></div></div><br class="figure-break"><p>
To communicate with the directory service, the client needs to share at
least two protocols with the server:
</p><div class="variablelist"><dl><dt><span class="term">LDAP</span></dt><dd><p>
LDAP is a protocol optimized for managing directory information. A
Windows domain controller with AD can use the LDAP protocol to
exchange directory information with the clients. To learn more about
LDAP in general and about the open source port of it, OpenLDAP, refer
to <a class="xref" href="cha.security.ldap.html" title="Chapter 4. LDAP—A Directory Service">Chapter 4, <i>LDAP—A Directory Service</i></a>.
</p></dd><dt><span class="term">Kerberos</span></dt><dd><p>
Kerberos is a third-party trusted authentication service. All its
clients trust Kerberos's authorization of another client's identity,
enabling kerberized single-sign-on (SSO) solutions. Windows supports a
Kerberos implementation, making Kerberos SSO possible even with Linux
clients. .
</p></dd></dl></div><p>
The following client components process account and authentication data:
</p><div class="variablelist"><dl><dt><span class="term">Winbind</span></dt><dd><p>
The most central part of this solution is the winbind daemon that is a
part of the Samba project and handles all communication with the AD
server.
</p></dd><dt><span class="term">NSS (<span class="emphasis"><em>Name Service Switch</em></span>)</span></dt><dd><p>
NSS routines provide name service information. Naming service for both
users and groups is provided by <code class="filename">nss_winbind</code>. This
module directly interacts with the winbind daemon.
</p></dd><dt><span class="term">PAM (<span class="emphasis"><em>Pluggable Authentication Modules</em></span>)</span></dt><dd><p>
User authentication for AD users is done by the
<code class="filename">pam_winbind</code> module. The creation of user homes
for the AD users on the Linux client is handled by
<code class="filename">pam_mkhomedir</code>. The
<code class="filename">pam_winbind</code> module directly interacts with
winbindd. To learn more about PAM in general, refer to
<a class="xref" href="cha.pam.html" title="Chapter 2. Authentication with PAM">Chapter 2, <i>Authentication with PAM</i></a>.
</p></dd></dl></div><p>
Applications that are PAM-aware, like the login routines and the GNOME
and KDE display managers, interact with the PAM and NSS layer to
authenticate against the Windows server. Applications supporting Kerberos
authentication (such as file managers, Web browsers, or e-mail clients)
use the Kerberos credential cache to access user's Kerberos tickets,
making them part of the SSO framework.
</p><div class="sect2" title="5.2.1. Domain Join"><div class="titlepage"><div><div><h3 class="title"><a name="sec.security.ad.background.domain_join"></a>5.2.1. Domain Join<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.security.ad.background.domain_join">¶</a></span></h3></div></div></div><p>
During domain join, the server and the client establish a secure
relation. On the client, the following tasks need to be performed to
join the existing LDAP and Kerberos SSO environment provided by the
Window domain controller. The entire join process is handled by the
YaST Domain Membership module, which can be run during installation or
in the installed system:
</p><div class="procedure"><ol class="procedure" type="1"><li><p>
The Windows domain controller providing both LDAP and KDC (Key
Distribution Center) services is located.
</p></li><li><p>
A machine account for the joining client is created in the directory
service.
</p></li><li><p>
An initial ticket granting ticket (TGT) is obtained for the client and
stored in its local Kerberos credential cache. The client needs this
TGT to get further tickets allowing it to contact other services, like
contacting the directory server for LDAP queries.
</p></li><li><p>
NSS and PAM configurations are adjusted to enable the client to
authenticate against the domain controller.
</p></li></ol></div><p>
During client boot, the winbind daemon is started and retrieves the
initial Kerberos ticket for the machine account. winbindd automatically
refreshes the machine's ticket to keep it valid. To keep track of the
current account policies, winbindd periodically queries the domain
controller.
</p></div><div class="sect2" title="5.2.2. Domain Login and User Homes"><div class="titlepage"><div><div><h3 class="title"><a name="sec.security.ad.background.logon"></a>5.2.2. Domain Login and User Homes<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.security.ad.background.logon">¶</a></span></h3></div></div></div><p>
The login managers of GNOME and KDE (GDM and KDM) have been extended to
allow the handling of AD domain login. Users can choose to log into the
primary domain the machine has joined or to one of the trusted domains
with which the domain controller of the primary domain has established a
trust relationship.
</p><p>
User authentication is mediated by a number of PAM modules as described
in <a class="xref" href="cha.security.ad.html#sec.security.ad.background" title="5.2. Background Information for Linux AD Support">Section 5.2, “Background Information for Linux AD Support”</a>. The
<code class="filename">pam_winbind</code> module used to authenticate clients
against Active Directory or NT4 domains is fully aware of Windows error
conditions that might prohibit a user's login. The Windows error codes
are translated into appropriate user-readable error messages that PAM
gives at login through any of the supported methods (GDM, KDM, console,
and SSH):
</p><div class="variablelist"><dl><dt><span class="term"><code class="literal">Password has expired</code>
</span></dt><dd><p>
The user sees a message stating that the password has expired and
needs to be changed. The system prompts for a new password and
informs the user if the new password does not comply with corporate
password policies (for example the password is too short, too simple,
or already in the history). If a user's password change fails, the
reason is shown and a new password prompt is given.
</p></dd><dt><span class="term"><code class="literal">Account disabled</code>
</span></dt><dd><p>
The user sees an error message stating that the account has been
disabled and to contact the system administrator.
</p></dd><dt><span class="term"><code class="literal">Account locked out</code>
</span></dt><dd><p>
The user sees an error message stating that the account has been
locked and to contact the system administrator.
</p></dd><dt><span class="term"><code class="literal">Password has to be changed</code>
</span></dt><dd><p>
The user can log in but receives a warning that the password needs to
be changed soon. This warning is sent three days before that password
expires. After expiration, the user cannot log in.
</p></dd><dt><span class="term"><code class="literal">Invalid workstation</code>
</span></dt><dd><p>
When a user is restricted to specific workstations and the current
openSUSE machine is not among them, a message appears that this
user cannot log in from this workstation.
</p></dd><dt><span class="term"><code class="literal">Invalid logon hours</code>
</span></dt><dd><p>
When a user is only allowed to log in during working hours and tries
to log in outside working hours, a message informs the user that
logging in is not possible at that time.
</p></dd><dt><span class="term"><code class="literal">Account expired</code>
</span></dt><dd><p>
An administrator can set an expiration time for a specific user
account. If that user tries to log in after expiration, the user gets
a message that the account has expired and cannot be used to log in.
</p></dd></dl></div><p>
During a successful authentication, <code class="filename">pam_winbind</code>
acquires a ticket granting ticket (TGT) from the Kerberos server of
Active Directory and stores it in the user's credential cache. It also
renews the TGT in the background, requiring no user interaction.
</p><p>
openSUSE supports local home directories for AD users. If
configured through YaST as described in
<a class="xref" href="cha.security.ad.html#sec.security.ad.config" title="5.3. Configuring a Linux Client for Active Directory">Section 5.3, “Configuring a Linux Client for Active Directory”</a>, user homes are created at the
first login of a Windows (AD) user into the Linux client. These home
directories look and feel entirely the same as standard Linux user home
directories and work independently of the AD domain controller. Using a
local user home, it is possible to access a user's data on this machine
(even when the AD server is disconnected) as long as the Linux client
has been configured to perform offline authentication.
</p><p>
It is also possible to mount server home directories automatically; for
more information, see Section “Configuring Clients” (Chapter 27, <i>Samba</i>, ↑Reference).
</p></div><div class="sect2" title="5.2.3. Offline Service and Policy Support"><div class="titlepage"><div><div><h3 class="title"><a name="sec.security.ad.background.offline"></a>5.2.3. Offline Service and Policy Support<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.security.ad.background.offline">¶</a></span></h3></div></div></div><p>
Users in a corporate environment must have the ability to become roaming
users (for example, to switch networks or even work disconnected for
some time). To enable users to log in to a disconnected machine,
extensive caching was integrated into the winbind daemon. The winbind
daemon enforces password policies even in the offline state. It tracks
the number of failed login attempts and reacts according to the policies
configured in Active Directory. Offline support is disabled by default
and must be explicitly enabled in the YaST Domain Membership module.
</p><p>
When the domain controller has become unavailable, the user can still
access network resources (other than the AD server itself) with valid
Kerberos tickets that have been acquired before losing the connection
(as in Windows). Password changes cannot be processed unless the domain
controller is online. While disconnected from the AD server, a user
cannot access any data stored on this server. When a workstation has
become disconnected from the network entirely and connects to the
corporate network again later, openSUSE acquires a new Kerberos
ticket as soon as the user has locked and unlocked the desktop (for
example, using a desktop screen saver).
</p></div></div><div class="sect1" title="5.3. Configuring a Linux Client for Active Directory"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="sec.security.ad.config"></a>5.3. Configuring a Linux Client for Active Directory<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.security.ad.config">¶</a></span></h2></div></div></div><p>
Before your client can join an AD domain, some adjustments must be made
to your network setup to ensure the flawless interaction of client and
server.
</p><div class="variablelist"><dl><dt><span class="term">DNS</span></dt><dd><p>
Configure your client machine to use a DNS server that can forward DNS
requests to the AD DNS server. Alternatively, configure your machine
to use the AD DNS server as the name service data source.
</p></dd><dt><span class="term">NTP</span></dt><dd><p>
To succeed with Kerberos authentication, the client must have have its
time set accurately. It is highly recommended to use a central NTP
time server for this purpose (this can be also the NTP server running
on your Active Directory domain controller). If the clock skew between
your Linux host and the domain controller exceeds a certain limit,
Kerberos authentication fails and the client is logged in using the
weaker NTLM (NT LAN Manager) authentication. For more details about
using active directory for time synchronization, see
<a class="xref" href="cha.security.ad.html#proc.ad.join" title="Procedure 5.1. Joining an AD Domain">Procedure 5.1, “Joining an AD Domain”</a>.
</p></dd><dt><span class="term">DHCP</span></dt><dd><p>
If your client uses dynamic network configuration with DHCP, configure
DHCP to provide the same IP and hostname to the client. If possible,
use static IP addresses.
</p></dd><dt><span class="term">Firewall</span></dt><dd><p>
To browse your network neighborhood, either disable the firewall
entirely or mark the interface used for browsing as part of the
internal zone.
</p><p>
To change the firewall settings on your client, log in as <code class="systemitem">root</code>
and start the YaST firewall module. Select
<span class="guimenu">Interfaces</span>. Select your network interface from the
list of interfaces and click <span class="guimenu">Change</span>. Select
<span class="guimenu">Internal Zone</span> and apply your settings with
<span class="guimenu">OK</span>. Leave the firewall settings with <span class="guimenu">Next</span>+<span class="guimenu">Accept</span>. To
disable the firewall, just set <span class="guimenu">Service Start</span> to
<span class="guimenu">Manually</span> and leave the firewall module with
<span class="guimenu">Next</span>+<span class="guimenu">Accept</span>.
</p></dd><dt><span class="term">AD Account</span></dt><dd><p>
You cannot log in to an AD domain unless the AD administrator has
provided you with a valid user account for that domain. Use the AD
username and password to log in to the AD domain from your Linux
client.
</p></dd></dl></div><p>
Join an existing AD domain during installation (or by later activating
SMB user authentication with YaST in the installed system).
</p><div class="note"><table border="0" cellpadding="3" cellspacing="0" width="100%" summary="Note"><tr class="head"><td width="32"><img alt="[Note]" src="admon/note.png"></td><th align="left"></th></tr><tr><td colspan="2" align="left" valign="top"><p>
Currently only a domain administrator account, such as
<code class="literal">Administrator</code>, can join openSUSE into Active
Directory.
</p></td></tr></table></div><p>
To join an AD domain in a running system, proceed as follows:
</p><div class="procedure" title="Procedure 5.1. Joining an AD Domain"><a name="proc.ad.join"></a><p class="title"><b>Procedure 5.1. Joining an AD Domain</b><span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#proc.ad.join">¶</a></span></p><ol class="procedure" type="1"><li><p>
Log in as <code class="systemitem">root</code> and start YaST.
</p></li><li><p>
Start <span class="guimenu">Network Services</span>+<span class="guimenu">Windows
Domain Membership</span>.
</p></li><li><p>
Enter the domain to join at <span class="guimenu">Domain or Workgroup</span> in
the <span class="guimenu">Windows Domain Membership</span> screen (see
<a class="xref" href="cha.security.ad.html#fig.ad.smbclient" title="Figure 5.2. Determining Windows Domain Membership">Figure 5.2, “Determining Windows Domain Membership”</a>). If the DNS settings on your host
are properly integrated with the Windows DNS server, enter the AD
domain name in its DNS format
(<code class="literal">mydomain.mycompany.com</code>). If you enter the short
name of your domain (also known as the pre–Windows 2000 domain
name), YaST must rely on NetBIOS name resolution instead of DNS to
find the correct domain controller. To select from a list of available
domains instead, use <span class="guimenu">Browse</span> to list the NetBIOS
domains then select the desired domain.
</p><div class="figure"><a name="fig.ad.smbclient"></a><p class="title"><b>Figure 5.2. Determining Windows Domain Membership</b><span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#fig.ad.smbclient">¶</a></span></p><div class="figure-contents"><div class="mediaobject"><table border="0" summary="manufactured viewport for HTML img" cellspacing="0" cellpadding="0" width="75%"><tr><td><img src="images/ad_sambaclient.png" width="100%" alt="Determining Windows Domain Membership"></td></tr></table></div></div></div><br class="figure-break"></li><li><p>
Check <span class="guimenu">Also Use SMB Information for Linux
Authentication</span> to use the SMB source for Linux
authentication.
</p></li><li><p>
Check <span class="guimenu">Create Home Directory on Login</span> to
automatically create a local home directory for your AD user on the
Linux machine.
</p></li><li><p>
Check <span class="guimenu">Offline Authentication</span> to allow your domain
users to log in even if the AD server is temporarily unavailable, or if
you do not have a network connection.
</p></li><li><p>
Select <span class="guimenu">Expert Settings</span>, if you want to change the
UID and GID ranges for the Samba users and groups. Let DHCP retrieve
the WINS server only if you need it. This is the case when some of your
machines are resolved only by the WINS system.
</p></li><li><p>
Configure NTP time synchronization for your AD environment by selecting
<span class="guimenu">NTP Configuration</span> and entering an appropriate server
name or IP address. This step is obsolete if you have already entered
the appropriate settings in the standalone YaST NTP configuration
module.
</p></li><li><p>
Click <span class="guimenu">Finish</span> and confirm the domain join when
prompted for it.
</p></li><li><p>
Provide the password for the Windows administrator on the AD server and
click <span class="guimenu">OK</span> (see <a class="xref" href="cha.security.ad.html#fig.ad.join1" title="Figure 5.3. Providing Administrator Credentials">Figure 5.3, “Providing Administrator Credentials”</a>).
</p><div class="figure"><a name="fig.ad.join1"></a><p class="title"><b>Figure 5.3. Providing Administrator Credentials</b><span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#fig.ad.join1">¶</a></span></p><div class="figure-contents"><div class="mediaobject"><table border="0" summary="manufactured viewport for HTML img" cellspacing="0" cellpadding="0" width="30%"><tr><td><img src="images/ad_join1.png" width="100%" alt="Providing Administrator Credentials"></td></tr></table></div></div></div><br class="figure-break"></li></ol></div><p>
After you have joined the AD domain, you can log in to it from your
workstation using the display manager of your desktop or the console.
</p></div><div class="sect1" title="5.4. Logging In to an AD Domain"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="sec.security.ad.login"></a>5.4. Logging In to an AD Domain<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.security.ad.login">¶</a></span></h2></div></div></div><p>
Provided your machine has been configured to authenticate against Active
Directory and you have a valid Windows user identity, you can log in to
your machine using the AD credentials. Login is supported for both
desktop environments (GNOME and KDE), the console, SSH, and any other
PAM-aware application.
</p><div class="important"><table border="0" cellpadding="3" cellspacing="0" width="100%" summary="Important: Offline Authentication"><tr class="head"><td width="32"><img alt="[Important]" src="admon/important.png"></td><th align="left">Offline Authentication</th></tr><tr><td colspan="2" align="left" valign="top"><p>
openSUSE supports offline authentication, allowing you to remain
logged in to your client machine even if the client machine is
disconnected from the network.
</p></td></tr></table></div><div class="sect2" title="5.4.1. GDM and KDM"><div class="titlepage"><div><div><h3 class="title"><a name="sec.security.ad.login.gui"></a>5.4.1. GDM and KDM<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.security.ad.login.gui">¶</a></span></h3></div></div></div><p>
To authenticate a GNOME client machine against an AD server, proceed as
follows:
</p><div class="procedure"><ol class="procedure" type="1"><li><p>
Select the domain.
</p></li><li><p>
Enter your Windows username and press <span class="keycap">Enter</span>.
</p></li><li><p>
Enter your Windows password and press <span class="keycap">Enter</span>.
</p></li></ol></div><p>
To authenticate a KDE client machine against an AD server, proceed as
follows:
</p><div class="procedure"><ol class="procedure" type="1"><li><p>
Select the domain.
</p></li><li><p>
Enter your Windows username.
</p></li><li><p>
Enter your Windows password and press <span class="keycap">Enter</span>.
</p></li></ol></div><p>
If configured to do so, openSUSE creates a user home directory on
the local machine on the first login of each AD authenticated user. This
allows you to benefit from the AD support of openSUSE while still
having a fully functional Linux machine at your disposal.
</p></div><div class="sect2" title="5.4.2. Console Login"><div class="titlepage"><div><div><h3 class="title"><a name="sec.security.ad.login.console"></a>5.4.2. Console Login<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.security.ad.login.console">¶</a></span></h3></div></div></div><p>
As well as logging into the AD client machine using a graphical
front-end, you can log in using the text-based console login or even
remotely using SSH.
</p><p>
To log in to your AD client from a console, enter
<code class="literal"><em class="replaceable"><code>DOMAIN</code></em>\<em class="replaceable"><code>user</code></em></code>
at the <code class="literal">login:</code> prompt and provide the password.
</p><p>
To remotely log in to your AD client machine using SSH, proceed as
follows:
</p><div class="procedure"><ol class="procedure" type="1"><li><p>
At the login prompt, enter:
</p><pre class="screen">ssh <em class="replaceable"><code>DOMAIN</code></em>\\<em class="replaceable"><code>user</code></em>@<em class="replaceable"><code>hostname</code></em>
</pre><p>
The <code class="literal">\</code> domain and login delimiter is escaped with
another <code class="literal">\</code> sign.
</p></li><li><p>
Provide the user's password.
</p></li></ol></div></div></div><div class="sect1" title="5.5. Changing Passwords"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="sec.security.ad.passwd"></a>5.5. Changing Passwords<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.security.ad.passwd">¶</a></span></h2></div></div></div><p>
openSUSE has the ability to help a user choose a suitable new
password that meets the corporate security policy. The underlying PAM
module retrieves the current password policy settings from the domain
controller, informing the user about the specific password quality
requirements a user account typically has by means of a message on login.
Like its Windows counterpart, openSUSE presents a message
describing:
</p><div class="itemizedlist"><ul class="itemizedlist" type="bullet"><li class="listitem" style="list-style-type: disc"><p>
Password history settings
</p></li><li class="listitem" style="list-style-type: disc"><p>
Minimum password length requirements
</p></li><li class="listitem" style="list-style-type: disc"><p>
Minimum password age
</p></li><li class="listitem" style="list-style-type: disc"><p>
Password complexity
</p></li></ul></div><p>
The password change process cannot succeed unless all requirements have
been successfully met. Feedback about the password status is given both
through the display managers and the console.
</p><p>
GDM and KDM provide feedback about password expiration and the prompt for
new passwords in an interactive mode. To change passwords in the display
managers, just provide the password information when prompted.
</p><p>
To change your Windows password, you can use the standard Linux utility,
<span class="command"><strong>passwd</strong></span>, instead of having to manipulate this data on
the server. To change your Windows password, proceed as follows:
</p><div class="procedure"><ol class="procedure" type="1"><li><p>
Log in at the console.
</p></li><li><p>
Enter <code class="literal">passwd</code>.
</p></li><li><p>
Enter your current password when prompted.
</p></li><li><p>
Enter the new password.
</p></li><li><p>
Reenter the new password for confirmation. If your new password does
not comply with the policies on the Windows server, this feedback is
given to you and you are prompted for another password.
</p></li></ol></div><p>
To change your Windows password from the GNOME desktop, proceed as
follows:
</p><div class="procedure"><ol class="procedure" type="1"><li><p>
Click the <span class="guimenu">Computer</span> icon on the left edge of the
panel.
</p></li><li><p>
Select <span class="guimenu">Control Center</span>.
</p></li><li><p>
From the <span class="guimenu">Personal</span> section, select <span class="guimenu">Change
Password</span>.
</p></li><li><p>
Enter your old password.
</p></li><li><p>
Enter and confirm the new password.
</p></li><li><p>
Leave the dialog with <span class="guimenu">Close</span> to apply your settings.
</p></li></ol></div><p>
To change your Windows password from the KDE desktop, proceed as follows:
</p><div class="procedure"><ol class="procedure" type="1"><li><p>
Select <span class="guimenu">Personal Settings</span> from the main menu.
</p></li><li><p>
Select <span class="guimenu">Security & Privacy</span>.
</p></li><li><p>
Click <span class="guimenu">Password & User Account</span>.
</p></li><li><p>
Click <span class="guimenu">Change Password</span>.
</p></li><li><p>
Enter your current password.
</p></li><li><p>
Enter and confirm the new password and apply your settings with
<span class="guimenu">OK</span>.
</p></li><li><p>
Leave the <span class="guimenu">Personal Settings</span> with <span class="guimenu">File</span>+<span class="guimenu">Quit</span>.
</p></li></ol></div></div></div><div class="navfooter"><table width="100%" summary="Navigation footer" border="0" class="bctable"><tr><td width="80%"><div class="breadcrumbs"><p><a href="index.html"> Documentation</a><span class="breadcrumbs-sep"> > </span><a href="book.security.html">Security Guide</a><span class="breadcrumbs-sep"> > </span><a href="part.auth.html">Authentication</a><span class="breadcrumbs-sep"> > </span><strong><a accesskey="p" title="Chapter 4. LDAP—A Directory Service" href="cha.security.ldap.html"><span>◀</span></a> <a accesskey="n" title="Chapter 6. Network Authentication with Kerberos" href="cha.security.kerberos.html"><span>▶</span></a></strong></p></div></td></tr></table></div></body></html>
ACC SHELL 2018