Kerberos is a third-party trusted authentication service. All its clients trust Kerberos authorization of another client's identity, enabling kerberized single-sign-on SSO solutions. Depending on which YaST module you use to set up Kerberos authentication, different client components process account and authentication data:. The sssd daemon is the central part of this solution.
It handles all communication with the Active Directory server. The winbindd daemon is the central part of this solution. Figure 8. 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. During domain join, the server and the client establish a secure relation. The entire join process is handled by the YaST Domain Membership module, which can be run during installation or in the installed system:.
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. NSS and PAM configurations are adjusted to enable the client to authenticate against the domain controller.
During client boot, the winbind daemon is started and retrieves the initial Kerberos ticket for the machine account. To keep track of the current account policies, winbindd periodically queries the domain controller. Users can choose to log in to 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.
User authentication is mediated by several PAM modules as described in Section 8. If there are errors, the error codes are translated into user-readable error messages that PAM gives at login through any of the supported methods GDM, console, and SSH :. 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. The user sees an error message stating that the account has been disabled and to contact the system administrator. The user sees an error message stating that the account has been locked and to contact the system administrator. 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. When a user is restricted to specific workstations and the current openSUSE Leap machine is not among them, a message appears that this user cannot log in from this workstation.
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. 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. During a successful authentication, the client 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. If configured through YaST as described in Section 8. These home directories look and feel identical to standard Linux user home directories and work independently of the Active Directory Domain Controller.
Using a local user home, it is possible to access a user's data on this machine even when the Active Directory server is disconnected as long as the Linux client has been configured to perform offline authentication. 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. When the domain controller has become unavailable, the user can still access network resources other than the Active Directory 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 Active Directory 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 Leap acquires a new Kerberos ticket when the user has locked and unlocked the desktop for example, using a desktop screen saver.
Before your client can join an Active Directory domain, some adjustments must be made to your network setup to ensure the flawless interaction of client and server. Alternatively, configure your machine to use the Active Directory DNS server as the name service data source. To succeed with Kerberos authentication, the client must 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.
For more details about using Active Directory for time synchronization, see Procedure 8. To browse your network neighborhood, either disable the firewall entirely or mark the interface used for browsing as part of the internal zone.
To change the firewall settings on your client, log in as root and start the YaST firewall module. Select Interfaces. Select your network interface from the list of interfaces and click Change.
Select Internal Zone and apply your settings with OK. You cannot log in to an Active Directory domain unless the Active Directory administrator has provided you with a valid user account for that domain.
Use the Active Directory user name and password to log in to the Active Directory domain from your Linux client. User logon management. This module is described in Section 8. For example, if you want to know which package provides the Perl module SVN::Core , use the following command:. Zypper, on the other hand, will tell you about providers of the capability from any repository, not only those that are installed.
To query single packages, use info with an exact package name as an argument. This displays detailed information about a package.
In case the package name does not match any package name from repositories, the command outputs detailed information for non-package matches. If you request a specific type by using the -t option and the type does not exist, the command outputs other available matches but without detailed information.
If you specify a source package, the command displays binary packages built from the source package. If you specify a binary package, the command outputs the source packages used to build the binary package. SUSE products are generally supported for 10 years. Often, you can extend that standard lifecycle by using the extended support offerings of SUSE which add three years of support.
To check the lifecycle of your product and the supported package, use the zypper lifecycle command as shown below:. Zypper now comes with a configuration file, allowing you to permanently change Zypper's behavior either system-wide or user-specific. Refer to the comments in the file for help about the available options. If you have trouble accessing packages from configured repositories for example, Zypper cannot find a certain package even though you know it exists in one of the repositories , refreshing the repositories may help:.
This forces a complete refresh and rebuild of the database, including a forced download of raw metadata. If the Btrfs file system is used on the root partition and snapper is installed, Zypper automatically calls snapper when committing changes to the file system to create appropriate file system snapshots.
These snapshots can be used to revert any changes made by Zypper. For more information on managing software from the command line, enter zypper help , zypper help COMMAND or refer to the zypper 8 man page. Its main commands are rpm and rpmbuild. The powerful RPM database can be queried by the users, system administrators and package builders for detailed information about the installed software.
Installable RPM archives are packed in a special binary format. These archives consist of the program files to install and certain meta information used during the installation by rpm to configure the software package or stored in the RPM database for documentation purposes. RPM archives normally have the extension. For several packages, the components needed for software development libraries, headers, include files, etc.
These development packages are only needed if you want to compile software yourself for example, the most recent GNOME packages. They can be identified by the name extension -devel , such as the packages alsa-devel and gimp-devel. This is especially recommended for update packages from the Internet. While fixing issues in the operating system, you might need to install a Problem Temporary Fix PTF into a production system.
To manually import the key, use the following command:. With this command the package is installed, but only if its dependencies are fulfilled and if there are no conflicts with other packages. With an error message, rpm requests those packages that need to be installed to meet dependency requirements.
In the background, the RPM database ensures that no conflicts arise—a specific file can only belong to one package. By choosing different options, you can force rpm to ignore these defaults, but this is only for experts.
Otherwise, you risk compromising the integrity of the system and possibly jeopardize the ability to update the system. This command removes the files of the old version and immediately installs the new files. The difference between the two versions is that -U installs packages that previously did not exist in the system, while -F merely updates previously installed packages.
When updating, rpm updates configuration files carefully using the following strategy:. If a configuration file was not changed by the system administrator, rpm installs the new version of the appropriate file.
No action by the system administrator is required. If a configuration file was changed by the system administrator before the update, rpm saves the changed file with the extension.
This is done only if the originally installed file and the newer version are different. If this is the case, compare the backup file. Afterward, delete all. Following an update,. In other words,. The -U switch is not only an equivalent to uninstalling with the -e option and installing with the -i option. Use -U whenever possible.
This command only deletes the package if there are no unresolved dependencies. Even in this case, RPM calls for assistance from the database. If such a deletion is, for whatever reason, impossible even if no additional dependencies exist , it may be helpful to rebuild the RPM database using the option --rebuilddb. The delta RPM packages are even smaller in size than patch RPMs, which is an advantage when transferring update packages over the Internet.
The makedeltarpm and applydelta binaries are part of the delta RPM suite package deltarpm and help you create and apply delta RPM packages. With the following commands, you can create a delta RPM called new. The following command assumes that old. Using applydeltarpm , you can reconstruct the new RPM from the file system if the old package is already installed:. To derive it from the old RPM without accessing the file system, use the -r option:. With the -q option rpm initiates queries, making it possible to inspect an RPM archive by adding the option -p and to query the RPM database of installed packages.
Several switches are available to specify the type of information required. See Table 6. File list with complete details to be used with -l , -c , or -d. List features of the package that another package can request with --requires. For example, the command rpm -q -i wget displays the information shown in Example 6.
The option -f only works if you specify the complete file name with its full path. Provide as many file names as desired. For example:. If only part of the file name is known, use a shell script as shown in Example 6. Pass the partial file name to the script shown as a parameter when running it.
With the installed RPM database, verification checks can be made. Initiate these with -V , or --verify. With this option, rpm shows all files in a package that have been changed since installation. In the case of configuration files, the letter c is printed. If the database is much larger than expected, it is useful to rebuild the database with the option --rebuilddb.
Before doing this, make a backup of the old database. The cron script cron. All source packages carry a. Source packages can be copied from the installation medium to the hard disk and unpacked with YaST. They are not, however, marked as installed [i] in the package manager.
This is because the source packages are not entered in the RPM database. Only installed operating system software is listed in the RPM database. Do not experiment with system components glibc , rpm , etc. The following example uses the wget. After installing the source package, you should have files similar to those in the following list:.
X is a wild card for various stages of the build process see the output of --help or the RPM documentation for details. The following is merely a brief explanation:. Do the same as -bp , but with additional installation of the built software. Caution: if the package does not support the BuildRoot feature, you might overwrite configuration files. Do the same as -bi , but with the additional creation of the binary package.
Do the same as -bb , but with the additional creation of the source RPM. The binary RPM created can now be installed with rpm -i or, preferably, with rpm -U. Installation with rpm makes it appear in the RPM database. If you still need this feature, use the --buildroot option as a workaround.
The danger with many packages is that unwanted files are added to the running system during the build process. To prevent this use build , which creates a defined environment in which the package is built. To establish this chroot environment, the build script must be provided with a complete package tree. Unlike rpm , the build command looks for the.
The package is built in this environment. The build script offers several additional options. For example, cause the script to prefer your own RPMs, omit the initialization of the build environment or limit the rpm command to one of the above-mentioned stages.
Access additional information with build --help and by reading the build man page. Midnight Commander mc can display the contents of RPM archives and copy parts of them. It represents archives as virtual file systems, offering all usual menu options of Midnight Commander. View the archive structure with the cursor keys and Enter.
Copy archive components with F5. A full-featured package manager is available as a YaST module. Snapper has a command-line interface and a YaST interface. Snapper lets you create and manage file system snapshots on the following types of file systems:.
Btrfs, a copy-on-write file system for Linux that natively supports file system snapshots of subvolumes. Subvolumes are separately mountable file systems within a physical partition. You can also boot from Btrfs snapshots. For more information, see Section 7. Undo system changes made by zypper and YaST. See Section 7. Restore files from previous snapshots. Do a system rollback by booting from a snapshot.
Manually create and manage snapshots, within the running system. If you disabled Snapper during the installation, you can enable it at any time later. To do so, create a default Snapper configuration for the root file system by running:.
Afterward enable the different snapshot types as described in Section 7. Note that on a Btrfs root file system, snapshots require a file system with subvolumes set up as proposed by the installer and a partition size of at least 16 GB. When a snapshot is created, both the snapshot and the original point to the same blocks in the file system. So, initially a snapshot does not occupy additional disk space. If data in the original file system is modified, changed data blocks are copied while the old data blocks are kept for the snapshot.
Therefore, a snapshot occupies the same amount of space as the data modified. So, over time, the amount of space a snapshot allocates, constantly grows. As a consequence, deleting files from a Btrfs file system containing snapshots may not free disk space!
Snapshots always reside on the same partition or subvolume on which the snapshot has been taken. It is not possible to store snapshots on a different partition or subvolume. As a result, partitions containing snapshots need to be larger than partitions not containing snapshots. The exact amount depends strongly on the number of snapshots you keep and the amount of data modifications. As a rule of thumb, give partitions twice as much space as you normally would.
To prevent disks from running out of space, old snapshots are automatically cleaned up. Refer to Section 7. Although snapshots themselves do not differ in a technical sense, we distinguish between three types of snapshots, based on the events that trigger them:. A single snapshot is created every hour. Old snapshots are automatically deleted. By default, the first snapshot of the last ten days, months, and years are kept.
Timeline snapshots are disabled by default. Installation snapshots are enabled by default. Administration snapshots are enabled by default. Some directories need to be excluded from snapshots for different reasons. The following list shows all directories that are excluded:. A rollback of the boot loader configuration is not supported. The directories listed above are architecture-specific. It is excluded to avoid uninstalling these applications on rollbacks.
This directory is used when manually installing software. It is excluded to avoid uninstalling these installations on rollbacks. Therefore this subvolume is created to exclude all of this variable data from snapshots and has Copy-On-Write disabled. However, all aspects of taking automatic snapshots and snapshot keeping can be configured according to your needs.
Each of the three snapshot types timeline, installation, administration can be enabled or disabled independently. Enabling: Install the package snapper-zypp-plugin. Disabling: Uninstall the package snapper-zypp-plugin.
Taking snapshot pairs upon installing packages with YaST or Zypper is handled by the snapper-zypp-plugin. By default the file looks like the following:. The match attribute defines whether the pattern is a Unix shell-style wild card w or a Python regular expression re.
If the given pattern matches and the corresponding package is marked as important for example kernel packages , the snapshot will also be marked as important. Pattern to match a package name. Based on the setting of the match attribute, special characters are either interpreted as shell wild cards or regular expressions. This pattern matches all package names starting with kernel-.
With this configuration snapshot, pairs are made whenever a package is installed line 9. When the kernel, dracut, glibc, systemd, or udev packages marked as important are installed, the snapshot pair will also be marked as important lines 4 to 8.
All rules are evaluated. To disable a rule, either delete it or deactivate it using XML comments. To prevent the system from making snapshot pairs for every package installation for example, comment line Such a subvolume will be excluded from snapshots.
You need to make sure not to create it inside an existing snapshot, since you would not be able to delete snapshots anymore after a rollback.
Any new subvolumes you create and permanently mount need to be created in this initial root file system. To do so, run the following commands. A subvolume may contain files that constantly change, such as virtualized disk images, database files, or log files. If so, consider disabling the copy-on-write feature for this volume, to avoid duplication of disk blocks.
Snapshots occupy disk space. To prevent disks from running out of space and thus causing system outages, old snapshots are automatically deleted. By default, up to ten important installation and administration snapshots and up to ten regular installation and administration snapshots are kept. A minimum of four important and two regular snapshots are always kept. You can adjust this configuration according to your needs as described in Section 7.
For this purpose, Snapper is configured to create a pair of snapshots before and after each run of zypper and YaST. Snapper also lets you restore system files that have been accidentally deleted or modified.
Timeline snapshots for the root partition need to be enabled for this purpose—see Section 7. By default, automatic snapshots as described above are configured for the root partition and its subvolumes. When working with snapshots to restore data, it is important to know that there are two fundamentally different scenarios Snapper can handle:. When undoing changes as described in the following, two snapshots are being compared and the changes between these two snapshots are made undone.
Using this method also allows to explicitly select the files that should be restored. When doing rollbacks as described in Section 7. When undoing changes, it is also possible to compare a snapshot against the current system. When restoring all files from such a comparison, this will have the same result as doing a rollback.
However, using the method described in Section 7. There is no mechanism to ensure data consistency when creating a snapshot. Whenever a file for example, a database is written at the same time as the snapshot is being created, it will result in a corrupted or partly written file.
Restoring such a file will cause problems. Therefore it is strongly recommended to always closely review the list of changed files and their diffs. Only restore files that really belong to the action you want to revert. If you set up the root partition with Btrfs during the installation, Snapper—preconfigured for doing rollbacks of YaST or Zypper changes—will automatically be installed.
Comparing two snapshots the tools also allow you to see which files have been changed. You can also display the differences between two versions of a file diff. Make sure Current Configuration is set to root. This is always the case unless you have manually added own Snapper configurations. Choose a pair of pre- and post-snapshots from the list. YaST snapshots are labeled as zypp y2base in the Description column ; Zypper snapshots are labeled zypp zypper.
Click Show Changes to open the list of files that differ between the two snapshots. Review the list of files. To restore one or more files, select the relevant files or directories by activating the respective check box. Click Restore Selected and confirm the action by clicking Yes. To restore a single file, activate its diff view by clicking its name.
Click Restore From First and confirm your choice with Yes. Get a list of YaST and Zypper snapshots by running snapper list -t pre-post. Get a list of changed files for a snapshot pair with snapper status PRE.. To display the diff for a certain file, run snapper diff PRE.. To restore one or more files run snapper -v undochange PRE..
Reverting user additions via undoing changes with Snapper is not recommended. Since certain directories are excluded from snapshots, files belonging to these users will remain in the file system. If a user with the same user ID as a deleted user is created, this user will inherit the files. Apart from the installation and administration snapshots, Snapper creates timeline snapshots. You can use these backup snapshots to restore files that have accidentally been deleted or to restore a previous version of a file.
By using Snapper's diff feature you can also find out which modifications have been made at a certain point of time. Being able to restore files is especially interesting for data, which may reside on subvolumes or partitions for which snapshots are not taken by default. Snapshots taken from the root file system defined by Snapper's root configuration , can be used to do a system rollback.
The recommended way to do such a rollback is to boot from the snapshot and then perform the rollback. Performing a rollback would also be possible by restoring all files from a root file system snapshot as described below. However, this is not recommended. Choose the Current Configuration from which to choose a snapshot. Select a timeline snapshot from which to restore a file and choose Show Changes. Timeline snapshots are of the type Single with a description value of timeline.
Select a file from the text box by clicking the file name. The difference between the snapshot version and the current system is shown. Activate the check box to select the file for restore.
Do so for all files you want to restore. Get a list of timeline snapshots for a specific configuration by running the following command:. Use snapper list-configs to display a list. Optionally list the differences between the current file version and the one from the snapshot by running.
Together with Snapper's rollback feature, this allows to recover a misconfigured system. Only snapshots created for the default Snapper configuration root are bootable. When booting a snapshot, the parts of the file system included in the snapshot are mounted read-only; all other file systems and parts that are excluded from snapshots are mounted read-write and can be modified. When undoing changes as described in Section 7. Using this method also allows to explicitly exclude selected files from being restored.
When doing rollbacks as described in the following, the system is reset to the state at which the snapshot was taken. To do a rollback from a bootable snapshot, the following requirements must be met. When doing a default installation, the system is set up accordingly. The root file system needs to be Btrfs. Booting from LVM volume snapshots is not supported. The root file system needs to be on a single device, a single partition and a single subvolume.
Boot the system. In the boot menu choose Bootable snapshots and select the snapshot you want to boot. The list of snapshots is listed by date—the most recent snapshot is listed first. Log in to the system. Carefully check whether everything works as expected. Note that you cannot write to any directory that is part of the snapshot. Data you write to other directories will not get lost, regardless of what you do next.
If the system is in a state where you do not want to do a rollback, reboot to boot into the current system state. You can then choose a different snapshot, or start the rescue system. On the boot screen, choose the default boot entry to reboot into the reinstated system. A snapshot of the file system status before the rollback is created. The default subvolume for root will be replaced with a fresh read-write snapshot. For details, see Section 7. It is useful to add a description for the snapshot with the -d option.
If snapshots are not disabled during installation, an initial bootable snapshot is created at the end of the initial system installation. You can go back to that state at any time by booting this snapshot. The snapshot can be identified by the description after installation. A bootable snapshot is also created when starting a system upgrade to a service pack or a new major release provided snapshots are not disabled.
Before a rollback is performed, a snapshot of the running file system is created. The description references the ID of the snapshot that was restored in the rollback. Snapshots created by rollbacks receive the value number for the Cleanup attribute. The rollback snapshots are therefore automatically deleted when the set number of snapshots is reached. If the snapshot contains important data, extract the data from the snapshot before it is removed. For example, after a fresh installation the following snapshots are available on the system:.
After running sudo snapper rollback snapshot 3 is created and contains the state of the system before the rollback was executed. Snapshot 4 is the new default Btrfs subvolume and thus the system after a reboot. To boot from a snapshot, reboot your machine and choose Start Bootloader from a read-only snapshot.
A screen listing all bootable snapshots opens. The most recent snapshot is listed first, the oldest last. Activating a snapshot from the boot menu does not reboot the machine immediately, but rather opens the boot loader of the selected snapshot. Each snapshot entry in the boot loader follows a naming scheme which makes it possible to identify it easily:. This field contains a description of the snapshot.
In case of a manually created snapshot this is the string created with the option --description or a custom string see Tip: Setting a Custom Description for Boot Loader Snapshot Entries. Long descriptions may be truncated, depending on the size of the boot screen. It is possible to replace the default string in the description field of a snapshot with a custom string. This is for example useful if an automatically created description is not sufficient, or a user-provided description is too long.
The description should be no longer than 25 characters—everything that exceeds this size will not be readable on the boot screen. A complete system rollback, restoring the complete system to the identical state as it was in when a snapshot was taken, is not possible. Root file system snapshots do not contain all directories. As a general consequence, data from these directories is not restored, resulting in the following limitations.
Re-install the application or the add-on to solve this problem. If a service or an application has established a new data format in between snapshot and current system, the application may not be able to read the affected data files after a rollback. A rollback may result in non-functional code.
If a rollback removes users from the system, data that is owned by these users in directories excluded from the snapshot, is not removed. If a user with the same user ID is created, this user will inherit the files. Use a tool like find to locate and remove orphaned files.
System users, for example database, system, and network admins who want to track copies of configuration files, documentation, and so on. It is possible to set this up manually see Section 7. By default it creates snapshots at user login and logout, and also creates time-based snapshots as some users remain logged in for extended periods of time. You may change the defaults using the normal Snapper commands and configuration files. By default the script performs a dry run.
Now you can create a new user:. Verify that the user's configuration was created by listing your Snapper configurations:. Over time, this output will become populated with a list of snapshots, which the user can manage with the standard Snapper commands. This removes the user, the user's home subvolume, Snapper configuration, and deletes all snapshots.
These are the steps for manually setting up users' home directories with Snapper. The way Snapper behaves is defined in a configuration file that is specific for each partition or Btrfs subvolume. The corresponding default configuration is named root. It creates and manages the YaST and Zypper snapshot.
As explained in Section 7. The amount depends on the amount of packages installed and the amount of changes made to the volume that is included in snapshots. The snapshot frequency and the number of snapshots that get archived also matter. There is a minimum root file system size that is required to automatically enable snapshots during the installation. Currently this size is approximately 12 GB. This value may change in the future, depending on architecture and the size of the base system.
Keep in mind that this value is a minimum size. Consider using more space for the root file system. As a rule of thumb, double the size you would use when not having enabled snapshots. You may create your own configurations for other partitions formatted with Btrfs or existing subvolumes on a Btrfs partition.
After a configuration has been created, you can either use snapper itself or the YaST Snapper module to restore files from these snapshots. In YaST you need to select your Current Configuration , while you need to specify your configuration for snapper with the global switch -c for example, snapper -c myconfig list.
To create a new Snapper configuration, run snapper create-config :. Mount point of the partition or Btrfs subvolume on which to take snapshots. To use your own set of defaults, create a copy of this file in the same directory and adjust it to your needs.
To use it, specify the -t option with the create-config command:. The snapper command offers several subcommands for managing existing configurations. You can list, show, delete and modify them:. Use the subcommand snapper list-configs to get all existing configurations:. For more information about the configuration options, see Section 7. Each configuration contains a list of options that can be modified from the command line.
The following list provides details for each option. Granting permissions to use snapshots to regular users. Defines whether pre and post snapshots should be compared in the background after creation. Defines the clean-up algorithm for snapshots pairs with identical pre and post snapshots. Defines the clean-up algorithm for installation and admin snapshots. Adds quota support to the clean-up algorithms. If Snapper is used by regular users see Section 7. If set to yes , hourly snapshots are created.
Valid values: yes , no. Defines the clean-up algorithm for timeline snapshots. By default Snapper can only be used by root. However, there are cases in which certain groups or users need to be able to create snapshots or undo changes by reverting to a snapshot:.
The corresponding. Note that all steps in this procedure need to be run by root. Select Interfaces. Select your network interface from the list of interfaces and click Change. Select Internal Zone and apply your settings with OK. You cannot log in to an AD domain unless the AD administrator has provided you with a valid user account for that domain. To select from a list of available domains instead, use Browse to list the NetBIOS domains then select the desired domain.
Check Offline Authentication 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. This is the case when some of your machines are resolved only by the WINS system. This step is obsolete if you have already entered the appropriate settings in the standalone YaST NTP configuration module. Click Finish and confirm the domain join when prompted for it.
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. 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.
If configured to do so, openSUSE creates a user home directory on the local machine on the first login of each AD authenticated user. 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. 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.
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.
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. To change your Windows password, you can use the standard Linux utility, passwd , instead of having to manipulate this data on the server.
To change your Windows password, proceed as follows:. 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.
From the Personal section, select Change Password. Enter and confirm the new password and apply your settings with OK. Quick Navigation: I. Active Directory Support. Contents 5. Integrating Linux and AD Environments 5. Configuring a Linux Client for Active Directory 5.
Logging In to an AD Domain 5. Changing Passwords. Integrating Linux and AD Environments. Accessing and Manipulating User Data on the Windows Server 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.
Offline Authentication 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. Single-Sign-On through Kerberized Applications Many applications of both desktops are Kerberos-enabled kerberized , 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.
Active Directory Authentication Schema. Kerberos Kerberos is a third-party trusted authentication service. Winbind 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. Domain Join. A machine account for the joining client is created in the directory service.
Domain Login and User Homes. Password has expired The user sees a message stating that the password has expired and needs to be changed. Account disabled The user sees an error message stating that the account has been disabled and to contact the system administrator.
Account locked out The user sees an error message stating that the account has been locked and to contact the system administrator. Password has to be changed The user can log in but receives a warning that the password needs to be changed soon.
0コメント