https://wiki.archlinux.org/api.php?action=feedcontributions&user=Twnaing&feedformat=atomArchWiki - User contributions [en]2024-03-29T13:53:09ZUser contributionsMediaWiki 1.41.0https://wiki.archlinux.org/index.php?title=Talk:Input_Leap&diff=684065Talk:Input Leap2021-06-27T12:03:27Z<p>Twnaing: Add "Change Fingerprint path and Describe the compatibility between Barrier and Synergy"</p>
<hr />
<div>==Synergy 1.7+ SSL encryption==<br />
Synergy 1.7+ replaces the existing crypto with an SSL transport plugin, according to http://synergy-project.org/wiki/Security. This is automatically configured for Synergy Pro users using the GUI, but can be compiled from source and installed manually for free. Might be worth touching on this in the encryption section, which is now outdated. [[User:Wlritchi|Wlritchi]] ([[User talk:Wlritchi|talk]]) 06:24, 3 June 2015 (UTC)<br />
<br />
== Update to Synergy 2.0 ==<br />
<br />
Fedora 26 is now on Synergy 2.0 - it breaks existing configurations/autostart/etc - so likely we're going to have to update the article very soon. :-| [[User:Zatricky|Zatricky]] ([[User talk:Zatricky|talk]]) 05:44, 8 February 2018 (UTC)<br />
<br />
* [[User:Pulec|Pulec]] ([[User talk:Pulec|talk]]) 21:31, 1 July 2018 (UTC): There is synergy2 binary https://aur.archlinux.org/packages/synergy2-bin, didn't tried it though, I am up for testing it and adding a section about config comability, someone could explain the legal level... and alternatives. BTW I am sure you can somehow get older RPM for Fedora and keep ideally same version pkgs. There is no reason for stop using synergy1 as long as its working.<br />
<br />
Significantly, though ''synergyc'' and ''synergys'' are provided, they both refer to using ''synergy-core --client'' and ''synergy-core --server'' instead. [[User:Zatricky|Zatricky]] ([[User talk:Zatricky|talk]]) 05:51, 8 February 2018 (UTC)<br />
<br />
== A tip about keystrokes, should be OS agnostic, not sure where to put it ==<br />
<br />
Default way for switching between clients is to go over the edge with mouse pointer (''perhaps redundant point''),<br />
for switching clients using keyboard only, there is a posibility for using hotkeys (keystrokes) like:<br />
<br />
(''is there way how to make nice shift key and such?'')<br />
<br />
* Win+` for switching to client on the right<br />
* Win+Shift+` for switching to client on the left<br />
<br />
Add following section called options (if you don't already have one)<br />
and define keystroke with switchInDirection argument<br />
<br />
<br />
section: options<br />
keystroke(Super+`) = switchInDirection(right)<br />
keystroke(Super+Shift+`) = switchInDirection(left)<br />
end<br />
<br />
(''not sure how to remove the indent'')<br />
<br />
== Change Fingerprint path and Describe the compatibility between Barrier and Synergy ==<br />
<br />
* [https://github.com/debauchee/barrier/wiki/Troubleshooting#fingerprint-trust Troubleshooting fingerprint trust on Barrier]<br />
* [https://github.com/debauchee/barrier/issues/227 synergy uses the Hello string Synergy%2i%2i, whereas barrier expects Barrier%2i%2i]<br />
<br />
[[User:Pulec|Pulec]] ([[User talk:Pulec|talk]]) 21:27, 1 July 2018 (UTC)</div>Twnainghttps://wiki.archlinux.org/index.php?title=Active_Directory_integration&diff=574158Active Directory integration2019-05-28T03:05:42Z<p>Twnaing: /* = OpenSource version */ removed extra =</p>
<hr />
<div>[[Category:Directory services]]<br />
[[es:Active Directory Integration]]<br />
[[ja:Active Directory Integration]]<br />
[[ru:Active Directory Integration]]<br />
{{Related articles start}}<br />
{{Related|Samba}}<br />
{{Related|Samba/Active Directory domain controller}}<br />
{{Related|SOGo}}<br />
{{Related articles end}}<br />
From [[w:Active Directory|Wikipedia]]:<br />
:Active Directory (AD) is a [[Wikipedia:directory service|directory service]] that Microsoft developed for [[Wikipedia:Windows domain|Windows domain]] networks.<br />
<br />
This article describes how to integrate an Arch Linux system with an existing Windows domain network using [[Samba]].<br />
<br />
Before continuing, you must have an existing Active Directory domain, and have a user with the appropriate rights within the domain to: query users and add computer accounts (Domain Join). <br />
<br />
This document is not an intended as a complete guide to Active Directory nor Samba. Refer to the resources section for additional information.<br />
<br />
Active Directory serves as a central location for network administration and security. It is responsible for authenticating and authorizing all users and computers within a Windows domain network, assigning and enforcing security policies for all computers in a network and installing or updating software on network computers. For example, when a user logs into a computer that is part of a Windows domain, it is Active Directory that verifies his or her password and specifies whether he or she is a system administrator or normal user. Server computers on which Active Directory is running are called domain controllers.<br />
<br />
Active Directory uses [[Wikipedia:Ldap|Lightweight Directory Access Protocol (LDAP)]] versions 2 and 3, Microsoft's version of [[Kerberos]] and DNS.<br />
<br />
== Terminology ==<br />
<br />
If you are not familiar with Active Directory, there are a few keywords that are helpful to know.<br />
<br />
* '''Domain''' : The name used to group computers and accounts. <br />
* '''SID''' : Each computer that joins the domain as a member must have a unique SID or System Identifier.<br />
* '''SMB''' : Server Message Block.<br />
* '''NETBIOS''': Network naming protocol used as an alternative to DNS. Mostly legacy, but still used in Windows Networking.<br />
* '''WINS''': Windows Information Naming Service. Used for resolving Netbios names to windows hosts.<br />
* '''Winbind''': Protocol for windows authentication.<br />
== Active Directory configuration ==<br />
This section works with the default configuration of Windows Server 2012 R2.<br />
<br />
=== GPO considerations ===<br />
Digital signing is enabled by default in Windows Server, and must be enabled at both the client and server level. For certain versions of Samba, Linux clients may experience issues connecting to the domain and/or shares. It's recommended you add the following parameters to your {{ic|smb.conf}} file: <br />
<br />
client signing = auto <br />
server signing = auto<br />
<br />
If that is not successful, you can disable ''Digital Sign Communication (Always)'' in the AD group policies. In your AD Group Policy editor, locate:<br />
<br />
Under ''Local policies > Security policies > Microsoft Network Server > Digital sign communication (Always)'' activate ''define this policy'' and use the ''disable'' radio button.<br />
<br />
If you use Windows Server 2008 R2, you need to modify that in ''GPO for Default Domain Controller Policy > Computer Setting > Policies > Windows Setting > Security Setting > Local Policies > Security Option > Microsoft network client: Digitally sign communications (always)''.<br />
<br />
Please note that disabling this GPO affects the security of all members of the domain.<br />
<br />
== Linux host configuration ==<br />
<br />
The next few steps will begin the process of configuring the Host. You will need root or sudo access to complete these steps.<br />
<br />
=== Installation ===<br />
<br />
[[Install]] the following packages:<br />
* {{Pkg|samba}}, see also [[Samba]]<br />
* {{Pkg|pam-krb5}}<br />
* {{Pkg|ntp}} or {{Pkg|openntpd}}, see also [[NTPd]] or [[OpenNTPD]]<br />
<br />
=== Updating DNS ===<br />
<br />
Active Directory is heavily dependent upon DNS. You will need to update {{ic|/etc/resolv.conf}} to use one or more of the Active Directory domain controllers:<br />
{{hc|/etc/resolv.conf|<br />
nameserver <IP1><br />
nameserver <IP2><br />
}}<br />
Replacing <IP1> and <IP2> with valid IP addresses for the AD servers. If your AD domains do not permit DNS forwarding or recursion, you may need to add additional resolvers. <br />
<br />
{{Note|If your machine dual boots Windows and Linux, you should use a different DNS hostname and netbios name for the linux configuration if both operating systems will be members of the same domain.}}<br />
<br />
=== Configuring NTP ===<br />
<br />
Read [[System time#Time synchronization]] to configure an NTP service.<br />
<br />
On the NTP servers configuration, use the IP addresses for the AD servers, as they typically run NTP as a service. Alternatively, you can use other known NTP servers provided the Active directory servers sync to the same stratum.<br />
<br />
Ensure that the service is configured to sync the time automatically very early on startup.<br />
<br />
=== Kerberos ===<br />
<br />
Let us assume that your AD is named example.com. Let us further assume your AD is ruled by two domain controllers, the primary and secondary one, which are named PDC and BDC, pdc.example.com and bdc.example.com respectively. Their IP adresses will be 192.168.1.2 and 192.168.1.3 in this example. Take care to watch your syntax; upper-case is very important here.<br />
<br />
{{hc|/etc/krb5.conf|<nowiki><br />
[libdefaults]<br />
default_realm = EXAMPLE.COM<br />
clockskew = 300<br />
ticket_lifetime = 1d<br />
forwardable = true<br />
proxiable = true<br />
dns_lookup_realm = true<br />
dns_lookup_kdc = true<br />
<br />
[realms]<br />
EXAMPLE.COM = {<br />
kdc = PDC.EXAMPLE.COM<br />
admin_server = PDC.EXAMPLE.COM<br />
default_domain = EXAMPLE.COM<br />
}<br />
<br />
[domain_realm]<br />
.kerberos.server = EXAMPLE.COM<br />
.example.com = EXAMPLE.COM<br />
example.com = EXAMPLE.COM<br />
example = EXAMPLE.COM<br />
<br />
[appdefaults]<br />
pam = {<br />
ticket_lifetime = 1d<br />
renew_lifetime = 1d<br />
forwardable = true<br />
proxiable = false<br />
retain_after_close = false<br />
minimum_uid = 0<br />
debug = false<br />
}<br />
<br />
[logging]<br />
default = FILE:/var/log/krb5libs.log<br />
kdc = FILE:/var/log/kdc.log<br />
admin_server = FILE:/var/log/kadmind.log<br />
</nowiki>}}<br />
<br />
{{Note|Heimdal 1.3.1 deprecated DES encryption which is required for AD authentication before Windows Server 2008. You will probably have to add {{bc|1=allow_weak_crypto = true}} to the {{Ic|[libdefaults]}} section.}}<br />
<br />
==== Creating a Kerberos ticket ====<br />
{{note|The keys and commands are user specific: sudo will be root, so your non-elevated account can connect to a different AD user with a separate key. If you only have one domain, it is not necessary to type @EXAMPLE.COM}}<br />
<br />
Now you can query the AD domain controllers and request a kerberos ticket ('''uppercase is necessary'''):<br />
{{bc|kinit administrator@EXAMPLE.COM}}<br />
<br />
You can use any username that has rights as a Domain Administrator.<br />
<br />
==== Validating the Ticket ====<br />
Run '''klist''' to verify you did receive the token. You should see something similar to:<br />
{{hc|# klist|<br />
Ticket cache: FILE:/tmp/krb5cc_0<br />
Default principal: administrator@EXAMPLE.COM<br />
<br />
Valid starting Expires Service principal <br />
02/04/12 21:27:47 02/05/12 07:27:42 krbtgt/EXAMPLE.COM@EXAMPLE.COM<br />
renew until 02/05/12 21:27:47<br />
}}<br />
<br />
=== pam_winbind.conf ===<br />
<br />
If you get errors stating that /etc/security/pam_winbind.conf was not found, create the file and add the following:<br />
<br />
{{hc|/etc/security/pam_winbind.conf|<nowiki><br />
[global]<br />
debug = no<br />
debug_state = no<br />
try_first_pass = yes<br />
krb5_auth = yes<br />
krb5_ccache_type = FILE<br />
cached_login = yes<br />
silent = no<br />
mkhomedir = yes<br />
</nowiki>}}<br />
<br />
With this setup, winbind will create user keytabs on the fly (krb5_ccache_type = FILE) at login and maintain them. You can verify this by simply running klist in a shell after logging in as an AD user but without needing to run kinit. You may need to set additional permissions on /etc/krb5.keytab eg 640 instead of 600 to get this to work (see {{Bug|52621}} for example)<br />
<br />
=== Samba ===<br />
Samba is a free software re-implementation of the SMB/CIFS networking protocol. It also includes tools for Linux machines to act as Windows networking servers and clients.<br />
<br />
{{Note|The configuration can vary greatly depending on how the Windows environment is deployed. Be prepared to troubleshoot and research}}<br />
<br />
In this section, we will focus on getting Authentication to work first by editing the 'Global' section first. Later, we will go back and add shares.<br />
<br />
{{hc|/etc/samba/smb.conf|<nowiki><br />
[Global]<br />
netbios name = MYARCHLINUX<br />
workgroup = EXAMPLE<br />
realm = EXAMPLE.COM<br />
server string = %h ArchLinux Host<br />
security = ads<br />
encrypt passwords = yes<br />
password server = pdc.example.com<br />
client signing = auto<br />
server signing = auto<br />
<br />
idmap config * : backend = tdb<br />
idmap config * : range = 10000-20000<br />
<br />
winbind use default domain = Yes<br />
winbind enum users = Yes<br />
winbind enum groups = Yes<br />
winbind nested groups = Yes<br />
winbind separator = +<br />
winbind refresh tickets = yes<br />
winbind offline logon = yes<br />
winbind cache time = 300<br />
<br />
template shell = /bin/bash<br />
template homedir = /home/%D/%U<br />
<br />
preferred master = no<br />
dns proxy = no<br />
wins server = pdc.example.com<br />
wins proxy = no<br />
<br />
inherit acls = Yes<br />
map acl inherit = Yes<br />
acl group control = yes<br />
<br />
load printers = no<br />
debug level = 3<br />
use sendfile = no<br />
</nowiki>}}<br />
<br />
=== Join the domain ===<br />
<br />
You need an AD Administrator account to do this. Let us assume this is named Administrator. The command is 'net ads join'<br />
{{hc|# net ads join -U Administrator|<br />
Administrator's password: xxx<br />
Using short domain name -- EXAMPLE<br />
Joined 'MYARCHLINUX' to realm 'EXAMPLE.COM'<br />
}}<br />
<br />
== Starting and testing services ==<br />
<br />
=== Starting Samba ===<br />
<br />
Hopefully, you have not rebooted yet! Fine. If you are in an X-session, quit it, so you can test login into another console, while you are still logged in.<br />
<br />
Enable and start the individual Samba daemons {{ic|smbd.service}}, {{ic|nmbd.service}}, and {{ic|winbindd.service}}.<br />
<br />
{{Note|In {{Pkg|samba}} 4.8.0-1, the Samba daemon units have been renamed from {{ic|smbd.service}}, {{ic|nmbd.service}}, and {{ic|winbindd.service}} to {{ic|smb.service}}, {{ic|nmb.service}}, and {{ic|winbind.service}}.}}<br />
<br />
Next we will need to modify the NSSwitch configuration, which tells the Linux host how to retrieve information from various sources and in which order to do so. In this case, we are appending Active Directory as additional sources for Users, Groups, and Hosts.<br />
<br />
{{hc|/etc/nsswitch.conf|<br />
passwd: files winbind<br />
shadow: files winbind<br />
group: files winbind <br />
<br />
hosts: files dns wins<br />
}}<br />
<br />
=== Testing Winbind ===<br />
Let us check if winbind is able to query the AD. The following command should return a list of AD users:<br />
<br />
{{hc|# wbinfo -u|<br />
administrator<br />
guest<br />
krbtgt<br />
test.user<br />
}}<br />
* Note we created an Active Directory user called 'test.user' on the domain controller<br />
<br />
We can do the same for AD groups:<br />
<br />
{{hc|# wbinfo -g|<br />
domain computers<br />
domain controllers<br />
schema admins<br />
enterprise admins<br />
cert publishers<br />
domain admins<br />
domain users<br />
domain guests<br />
group policy creator owners<br />
ras and ias servers<br />
allowed rodc password replication group<br />
denied rodc password replication group<br />
read-only domain controllers<br />
enterprise read-only domain controllers<br />
dnsadmins<br />
dnsupdateproxy<br />
}}<br />
<br />
=== Testing nsswitch ===<br />
<br />
To ensure that our host is able to query the domain for users and groups, we test nsswitch settings by issuing the 'getent' command.<br />
<br />
If user accounts from your DC are not showing, try adding the following line to your smb.conf file:<br />
{{hc|/etc/samba/smb.conf|<nowiki><br />
winbind trusted domains only = no<br />
</nowiki>}}<br />
<br />
The following output shows what a stock ArchLinux install looks like:<br />
<br />
{{hc|# getent passwd|<br />
root:x:0:0:root:/root:/bin/bash<br />
bin:x:1:1:bin:/bin:/bin/false<br />
daemon:x:2:2:daemon:/sbin:/bin/false<br />
mail:x:8:12:mail:/var/spool/mail:/bin/false<br />
ftp:x:14:11:ftp:/srv/ftp:/bin/false<br />
http:x:33:33:http:/srv/http:/bin/false<br />
nobody:x:99:99:nobody:/:/bin/false<br />
dbus:x:81:81:System message bus:/:/bin/false<br />
ntp:x:87:87:Network Time Protocol:/var/empty:/bin/false<br />
avahi:x:84:84:avahi:/:/bin/false<br />
administrator:*:10001:10006:Administrator:/home/EXAMPLE/administrator:/bin/bash<br />
guest:*:10002:10007:Guest:/home/EXAMPLE/guest:/bin/bash<br />
krbtgt:*:10003:10006:krbtgt:/home/EXAMPLE/krbtgt:/bin/bash<br />
test.user:*:10000:10006:Test User:/home/EXAMPLE/test.user:/bin/bash<br />
}}<br />
<br />
And for groups:<br />
{{hc|# getent group|<br />
root:x:0:root<br />
bin:x:1:root,bin,daemon<br />
daemon:x:2:root,bin,daemon<br />
sys:x:3:root,bin<br />
adm:x:4:root,daemon<br />
tty:x:5:<br />
disk:x:6:root<br />
lp:x:7:daemon<br />
mem:x:8:<br />
kmem:x:9:<br />
wheel:x:10:root<br />
ftp:x:11:<br />
mail:x:12:<br />
uucp:x:14:<br />
log:x:19:root<br />
utmp:x:20:<br />
locate:x:21:<br />
rfkill:x:24:<br />
smmsp:x:25:<br />
http:x:33:<br />
games:x:50:<br />
network:x:90:<br />
video:x:91:<br />
audio:x:92:<br />
optical:x:93:<br />
floppy:x:94:<br />
storage:x:95:<br />
scanner:x:96:<br />
power:x:98:<br />
nobody:x:99:<br />
users:x:100:<br />
dbus:x:81:<br />
ntp:x:87:<br />
avahi:x:84:<br />
domain computers:x:10008:<br />
domain controllers:x:10009:<br />
schema admins:x:10010:administrator<br />
enterprise admins:x:10011:administrator<br />
cert publishers:x:10012:<br />
domain admins:x:10013:test.user,administrator<br />
domain users:x:10006:<br />
domain guests:x:10007:<br />
group policy creator owners:x:10014:administrator<br />
ras and ias servers:x:10015:<br />
allowed rodc password replication group:x:10016:<br />
denied rodc password replication group:x:10017:krbtgt<br />
read-only domain controllers:x:10018:<br />
enterprise read-only domain controllers:x:10019:<br />
dnsadmins:x:10020:<br />
dnsupdateproxy:x:10021:<br />
}}<br />
<br />
=== Testing Samba commands ===<br />
<br />
Try out some net commands to see if Samba can communicate with AD:<br />
<br />
{{hc|# net ads info|<nowiki><br />
[2012/02/05 20:21:36.473559, 0] param/loadparm.c:7599(lp_do_parameter)<br />
Ignoring unknown parameter "idmapd backend"<br />
LDAP server: 192.168.1.2<br />
LDAP server name: PDC.example.com<br />
Realm: EXAMPLE.COM<br />
Bind Path: dc=EXAMPLE,dc=COM<br />
LDAP port: 389<br />
Server time: Sun, 05 Feb 2012 20:21:33 CST<br />
KDC server: 192.168.1.2<br />
Server time offset: -3<br />
</nowiki>}}<br />
<br />
{{hc|# net ads lookup|<br />
[2012/02/05 20:22:39.298823, 0] param/loadparm.c:7599(lp_do_parameter)<br />
Ignoring unknown parameter "idmapd backend"<br />
Information for Domain Controller: 192.168.1.2<br />
<br />
Response Type: LOGON_SAM_LOGON_RESPONSE_EX<br />
GUID: 2a098512-4c9f-4fe4-ac22-8f9231fabbad<br />
Flags:<br />
Is a PDC: yes<br />
Is a GC of the forest: yes<br />
Is an LDAP server: yes<br />
Supports DS: yes<br />
Is running a KDC: yes<br />
Is running time services: yes<br />
Is the closest DC: yes<br />
Is writable: yes<br />
Has a hardware clock: yes<br />
Is a non-domain NC serviced by LDAP server: no<br />
Is NT6 DC that has some secrets: no<br />
Is NT6 DC that has all secrets: yes<br />
Forest: example.com<br />
Domain: example.com<br />
Domain Controller: PDC.example.com<br />
Pre-Win2k Domain: EXAMPLE<br />
Pre-Win2k Hostname: PDC<br />
Server Site Name : Office<br />
Client Site Name : Office<br />
NT Version: 5<br />
LMNT Token: ffff<br />
LM20 Token: ffff<br />
}}<br />
<br />
{{hc|<nowiki># net ads status -U administrator%password | less</nowiki>|<nowiki><br />
objectClass: top<br />
objectClass: person<br />
objectClass: organizationalPerson<br />
objectClass: user<br />
objectClass: computer<br />
cn: myarchlinux<br />
distinguishedName: CN=myarchlinux,CN=Computers,DC=leafscale,DC=inc<br />
instanceType: 4<br />
whenCreated: 20120206043413.0Z<br />
whenChanged: 20120206043414.0Z<br />
uSNCreated: 16556<br />
uSNChanged: 16563<br />
name: myarchlinux<br />
objectGUID: 2c24029c-8422-42b2-83b3-a255b9cb41b3<br />
userAccountControl: 69632<br />
badPwdCount: 0<br />
codePage: 0<br />
countryCode: 0<br />
badPasswordTime: 0<br />
lastLogoff: 0<br />
lastLogon: 129729780312632000<br />
localPolicyFlags: 0<br />
pwdLastSet: 129729764538848000<br />
primaryGroupID: 515<br />
objectSid: S-1-5-21-719106045-3766251393-3909931865-1105<br />
...<snip>...<br />
</nowiki>}}<br />
<br />
== Configuring PAM ==<br />
<br />
Now we will change various rules in PAM to allow Active Directory users to use the system for things like login and sudo access. When changing the rules, note the order of these items and whether they are marked as '''required''' or '''sufficient''' is critical to things working as expected. You should not deviate from these rules unless you know how to write PAM rules.<br />
<br />
In case of logins, PAM should first ask for AD accounts, and for local accounts if no matching AD account was found. Therefore, we add entries to include {{ic|pam_winbind.so}} into the authentication process.<br />
<br />
The Arch Linux PAM configuration keeps the central auth process in {{ic|/etc/pam.d/system-auth}}. Starting with the stock configuration from {{ic|pambase}}, change it like this:<br />
<br />
=== system-auth ===<br />
<br />
==== "auth" section ====<br />
<br />
Find the line:<br />
<br />
auth required pam_unix.so ...<br />
<br />
Delete it, and replace with:<br />
<br />
auth [success=1 default=ignore] pam_localuser.so<br />
auth [success=2 default=die] pam_winbind.so<br />
auth [success=1 default=die] pam_unix.so nullok<br />
auth requisite pam_deny.so<br />
<br />
==== "account" section ====<br />
<br />
Find the line:<br />
<br />
account required pam_unix.so<br />
<br />
Keep it, and add this below:<br />
<br />
account [success=1 default=ignore] pam_localuser.so<br />
account required pam_winbind.so<br />
<br />
==== "password" section ====<br />
<br />
Find the line:<br />
<br />
password required pam_unix.so ...<br />
<br />
Delete it, and replace with:<br />
<br />
password [success=1 default=ignore] pam_localuser.so<br />
password [success=2 default=die] pam_winbind.so<br />
password [success=1 default=die] pam_unix.so sha512 shadow<br />
password requisite pam_deny.so<br />
<br />
==== "session" section ====<br />
<br />
Find the line:<br />
<br />
session required pam_unix.so<br />
<br />
Keep it, and add this line immediately above it:<br />
<br />
session required pam_mkhomedir.so skel=/etc/skel/ umask=0022<br />
<br />
Below the pam_unix line, add these:<br />
<br />
session [success=1 default=ignore] pam_localuser.so<br />
session required pam_winbind.so<br />
<br />
=== passwd ===<br />
<br />
==== "password" section ====<br />
<br />
In order for logged-in Active Directory users to be able to change their passwords with the 'passwd' command, the file {{ic|/etc/pam.d/passwd}} must include the information from system-auth.<br />
<br />
Find the line:<br />
<br />
password required pam_unix.so sha512 shadow nullok<br />
<br />
Delete it, and replace with:<br />
<br />
password include system-auth<br />
<br />
=== Testing login ===<br />
<br />
Now, start a new console session (or ssh) and try to login using the AD credentials. The domain name is optional, as this was set in the Winbind configuration as 'default realm'. Please note that in the case of ssh, you will need to modify the {{ic|/etc/ssh/sshd_config}} file to allow kerberos authentication {{ic|(KerberosAuthentication yes)}}.<br />
<br />
{{bc|<br />
test.user<br />
EXAMPLE+test.user<br />
}}<br />
<br />
Both should work. You should notice that {{ic|/home/example/test.user}} will be automatically created.<br />
'''Log into another session using an linux account. Check that you still be able to log in as root - but keep in mind to be logged in as root in at least one session!'''<br />
<br />
== Configuring Shares ==<br />
Earlier we skipped configuration of the shares. Now that things are working, go back to {{ic|/etc/samba/smb.conf}}, and add the exports for the host that you want available on the windows network. <br />
<br />
{{hc|/etc/samba/smb.conf|<nowiki><br />
[MyShare]<br />
comment = Example Share<br />
path = /srv/exports/myshare<br />
read only = no<br />
browseable = yes<br />
valid users = @NETWORK+"Domain Admins" NETWORK+test.user<br />
</nowiki>}}<br />
<br />
In the above example, the keyword '''NETWORK''' is to be used. Do not mistakenly substitute this with your domain name. For adding groups, prepend the '@' symbol to the group. Note that {{ic|Domain Admins}} is encapsulated in quotes so Samba correctly parses it when reading the configuration file.<br />
<br />
== Adding a machine keytab file and activating password-free kerberized ssh to the machine ==<br />
This explains how to generate a machine keytab file which you will need e.g. to enable password-free kerberized ssh to your machine from other machines in the domain. The scenario in mind is that you have a bunch of systems in your domain and you just added a server/workstation using the above description to your domain onto which a lot of users need to ssh in order to work - e.g. GPU workstation or an OpenMP compute node, etc. In this case you might not want to type your password every time you log in. On the other hand the key authentication used by many users in this case can not give you the necessary credentials to e.g. mount kerberized NFSv4 shares. So this will help you to enable password-free logins from your clients to the machine in question using kerberos ticket forwarding.<br />
<br />
=== Creating a machine key tab file ===<br />
run 'net ads keytab create -U administrator' as root to create a machine keytab file in /etc/krb5.keytab. It will prompt you with a warning that we need to enable keytab authentication in our configuration file, so we will do that in the next step. In my case it had problems when a key tab file is already in place - the command just did not come back it hang ... In that case you should rename the existing /etc/krb5.keytab and run the command again - it should work now.<br />
<br />
{{bc|# net ads keytab create -U administrator}}<br />
<br />
verify the content of your keytab by running:<br />
<br />
{{hc|# klist -k /etc/krb5.keytab|<nowiki><br />
Keytab name: FILE:/etc/krb5.keytab<br />
KVNO Principal<br />
---- --------------------------------------------------------------------------<br />
4 host/myarchlinux.example.com@EXAMPLE.COM<br />
4 host/myarchlinux.example.com@EXAMPLE.COM<br />
4 host/myarchlinux.example.com@EXAMPLE.COM<br />
4 host/myarchlinux.example.com@EXAMPLE.COM<br />
4 host/myarchlinux.example.com@EXAMPLE.COM<br />
4 host/MYARCHLINUX@EXAMPLE.COM<br />
4 host/MYARCHLINUX@EXAMPLE.COM<br />
4 host/MYARCHLINUX@EXAMPLE.COM<br />
4 host/MYARCHLINUX@EXAMPLE.COM<br />
4 host/MYARCHLINUX@EXAMPLE.COM<br />
4 MYARCHLINUX$@EXAMPLE.COM<br />
4 MYARCHLINUX$@EXAMPLE.COM<br />
4 MYARCHLINUX$@EXAMPLE.COM<br />
4 MYARCHLINUX$@EXAMPLE.COM<br />
4 MYARCHLINUX$@EXAMPLE.COM<br />
</nowiki>}}<br />
<br />
=== Enabling keytab authentication ===<br />
Now you need to tell winbind to use the file by adding these lines to the /etc/samba/smb.conf:<br />
<br />
kerberos method = secrets and keytab<br />
dedicated keytab file = /etc/krb5.keytab<br />
<br />
It should look something like this:<br />
<br />
{{hc|/etc/samba/smb.conf|<nowiki><br />
[Global]<br />
netbios name = MYARCHLINUX<br />
workgroup = EXAMPLE<br />
realm = EXAMPLE.COM<br />
server string = %h ArchLinux Host<br />
security = ads<br />
encrypt passwords = yes<br />
password server = pdc.example.com<br />
kerberos method = secrets and keytab<br />
dedicated keytab file = /etc/krb5.keytab<br />
<br />
idmap config * : backend = tdb<br />
idmap config * : range = 10000-20000<br />
<br />
winbind use default domain = Yes<br />
winbind enum users = Yes<br />
winbind enum groups = Yes<br />
winbind nested groups = Yes<br />
winbind separator = +<br />
winbind refresh tickets = yes<br />
<br />
template shell = /bin/bash<br />
template homedir = /home/%D/%U<br />
<br />
preferred master = no<br />
dns proxy = no<br />
wins server = pdc.example.com<br />
wins proxy = no<br />
<br />
inherit acls = Yes<br />
map acl inherit = Yes<br />
acl group control = yes<br />
<br />
load printers = no<br />
debug level = 3<br />
use sendfile = no<br />
</nowiki>}}<br />
<br />
Restart the winbind daemon using 'systemctl restart winbindd.service' with root privileges.<br />
<br />
{{bc|# systemctl restart winbindd.service}}<br />
<br />
Check if everything works by getting a machine ticket for your system by running <br />
<br />
{{bc|# kinit MYARCHLINUX$ -kt /etc/krb5.keytab}}<br />
<br />
This should not give you any feedback but running 'klist' should show you sth like:<br />
<br />
{{hc|# klist|<br />
Ticket cache: FILE:/tmp/krb5cc_0<br />
Default principal: MYARCHLINUX$@EXAMPLE.COM<br />
<br />
Valid starting Expires Service principal <br />
02/04/12 21:27:47 02/05/12 07:27:42 krbtgt/EXAMPLE.COM@EXAMPLE.COM<br />
renew until 02/05/12 21:27:47<br />
}}<br />
<br />
Some common mistakes here are a) forgetting the trailing $ or b) ignoring case sensitivity - it needs to look exactly like the entry in the keytab (usually you cannot to much wrong with all capital)<br />
<br />
=== Preparing sshd on server ===<br />
<br />
All we need to do is add some options to our sshd_config and restart the sshd.service.<br />
<br />
Edit /etc/ssh/sshd_config to look like this in the appropriate places:<br />
<br />
{{hc|# /etc/ssh/sshd_config|<br />
<br />
...<br />
<br />
# Change to no to disable s/key passwords<br />
ChallengeResponseAuthentication no<br />
<br />
# Kerberos options<br />
KerberosAuthentication yes<br />
#KerberosOrLocalPasswd yes<br />
KerberosTicketCleanup yes<br />
KerberosGetAFSToken yes<br />
<br />
# GSSAPI options<br />
GSSAPIAuthentication yes<br />
GSSAPICleanupCredentials yes<br />
<br />
...<br />
<br />
}}<br />
<br />
Restart the sshd.service using:<br />
<br />
{{bc|# systemctl restart sshd.service}}<br />
<br />
=== Adding necessary options on client ===<br />
<br />
First we need to make sure that the tickets on our client are forwardable. This is usually standard but we better check anyways. You have to look for the forwardable option and set it to 'true' in the Kerberos config file /etc/krb5.conf<br />
<br />
{{bc|<nowiki>forwardable = true</nowiki>}}<br />
<br />
Secondly we need to add the options <br />
<br />
GSSAPIAuthentication yes<br />
GSSAPIDelegateCredentials yes<br />
<br />
to our .ssh/config file to tell ssh to use this options - alternatively they can be invoked using the -o options directly in the ssh command (see 'man ssh' for help).<br />
<br />
=== Testing the setup ===<br />
On Client:<br />
<br />
make sure you have a valid ticket - if in doubt run 'kinit'<br />
<br />
then use ssh to connect to you machine<br />
<br />
{{bc|ssh myarchlinux.example.com }}<br />
<br />
you should get connected without needing to enter your password.<br />
<br />
if you have key authentication additionally activated then you should perform<br />
<br />
{{bc|ssh -v myarchlinux.example.com }}<br />
<br />
to see which authentication method it actually uses.<br />
<br />
For debugging you can enable DEBUG3 on the server and look into the journal using [[journalctl]].<br />
<br />
=== Nifty fine-tuning for complete password-free kerberos handling. ===<br />
<br />
In case your clients are not using domain accounts on their local machines (for whatever reason) it can be hard to actually teach them to kinit before ssh to the workstation. Therefore I came up with a nice workaround:<br />
<br />
== Generating user Keytabs which are accepted by AD ==<br />
<br />
On a system let the user run:<br />
<br />
{{bc|<nowiki><br />
ktutil<br />
addent -password -p username@EXAMPLE.COM -k 1 -e RC4-HMAC<br />
- enter password for username -<br />
wkt username.keytab<br />
q<br />
</nowiki>}}<br />
<br />
Now test the file by invoking:<br />
<br />
{{bc|kinit username@EXAMPLE.COM -kt username.keytab}}<br />
<br />
It should not promt you to give your password nor should it give any other feedback. If it worked you are basically done - just put the line above into your ~./bashrc - you can now get kerberos tickets without typing a password and with that you can connect to your workstation without typing a password while being completely kerberized and able to authenticate against NFSv4 and CIFS via tickets - pretty neat.<br />
<br />
=== Nice to know ===<br />
<br />
The file 'username.keytab' is not machinespecific and can therefore be copied around. E.g. we created the files on a linux machine and copied them to our Mac clients as the commands on Macs are different ...<br />
<br />
== See also ==<br />
<br />
* [[wikipedia:Active_Directory|Wikipedia - Active Directory]]<br />
* [[wikipedia:Samba_(software)|Wikipedia - Samba]]<br />
* [[wikipedia:Kerberos_(protocol)|Wikipedia - Kerberos]]<br />
* [http://www.samba.org/samba/docs Samba - Documentation]<br />
* [http://wiki.samba.org/index.php/Samba_&_Active_Directory Samba Wiki - Samba & Active Directory]<br />
* [http://www.samba.org/samba/docs/man/manpages-3/smb.conf.5.html {{ic|smb.conf(5)}} manpage]<br />
=== Commercial Solutions ===<br />
* Centrify<br />
* Likewise<br />
<br />
=== OpenSource version ===<br />
* [https://github.com/BeyondTrust/pbis-open/ PowerBroker Identity Services Open]: formerly Likewise acquired by BeyondTrust<br />
* [https://www.centrify.com/express/linux/ Centrify Express for Linux]</div>Twnainghttps://wiki.archlinux.org/index.php?title=Active_Directory_integration&diff=574157Active Directory integration2019-05-28T03:05:10Z<p>Twnaing: add opensource version of commercial solution</p>
<hr />
<div>[[Category:Directory services]]<br />
[[es:Active Directory Integration]]<br />
[[ja:Active Directory Integration]]<br />
[[ru:Active Directory Integration]]<br />
{{Related articles start}}<br />
{{Related|Samba}}<br />
{{Related|Samba/Active Directory domain controller}}<br />
{{Related|SOGo}}<br />
{{Related articles end}}<br />
From [[w:Active Directory|Wikipedia]]:<br />
:Active Directory (AD) is a [[Wikipedia:directory service|directory service]] that Microsoft developed for [[Wikipedia:Windows domain|Windows domain]] networks.<br />
<br />
This article describes how to integrate an Arch Linux system with an existing Windows domain network using [[Samba]].<br />
<br />
Before continuing, you must have an existing Active Directory domain, and have a user with the appropriate rights within the domain to: query users and add computer accounts (Domain Join). <br />
<br />
This document is not an intended as a complete guide to Active Directory nor Samba. Refer to the resources section for additional information.<br />
<br />
Active Directory serves as a central location for network administration and security. It is responsible for authenticating and authorizing all users and computers within a Windows domain network, assigning and enforcing security policies for all computers in a network and installing or updating software on network computers. For example, when a user logs into a computer that is part of a Windows domain, it is Active Directory that verifies his or her password and specifies whether he or she is a system administrator or normal user. Server computers on which Active Directory is running are called domain controllers.<br />
<br />
Active Directory uses [[Wikipedia:Ldap|Lightweight Directory Access Protocol (LDAP)]] versions 2 and 3, Microsoft's version of [[Kerberos]] and DNS.<br />
<br />
== Terminology ==<br />
<br />
If you are not familiar with Active Directory, there are a few keywords that are helpful to know.<br />
<br />
* '''Domain''' : The name used to group computers and accounts. <br />
* '''SID''' : Each computer that joins the domain as a member must have a unique SID or System Identifier.<br />
* '''SMB''' : Server Message Block.<br />
* '''NETBIOS''': Network naming protocol used as an alternative to DNS. Mostly legacy, but still used in Windows Networking.<br />
* '''WINS''': Windows Information Naming Service. Used for resolving Netbios names to windows hosts.<br />
* '''Winbind''': Protocol for windows authentication.<br />
== Active Directory configuration ==<br />
This section works with the default configuration of Windows Server 2012 R2.<br />
<br />
=== GPO considerations ===<br />
Digital signing is enabled by default in Windows Server, and must be enabled at both the client and server level. For certain versions of Samba, Linux clients may experience issues connecting to the domain and/or shares. It's recommended you add the following parameters to your {{ic|smb.conf}} file: <br />
<br />
client signing = auto <br />
server signing = auto<br />
<br />
If that is not successful, you can disable ''Digital Sign Communication (Always)'' in the AD group policies. In your AD Group Policy editor, locate:<br />
<br />
Under ''Local policies > Security policies > Microsoft Network Server > Digital sign communication (Always)'' activate ''define this policy'' and use the ''disable'' radio button.<br />
<br />
If you use Windows Server 2008 R2, you need to modify that in ''GPO for Default Domain Controller Policy > Computer Setting > Policies > Windows Setting > Security Setting > Local Policies > Security Option > Microsoft network client: Digitally sign communications (always)''.<br />
<br />
Please note that disabling this GPO affects the security of all members of the domain.<br />
<br />
== Linux host configuration ==<br />
<br />
The next few steps will begin the process of configuring the Host. You will need root or sudo access to complete these steps.<br />
<br />
=== Installation ===<br />
<br />
[[Install]] the following packages:<br />
* {{Pkg|samba}}, see also [[Samba]]<br />
* {{Pkg|pam-krb5}}<br />
* {{Pkg|ntp}} or {{Pkg|openntpd}}, see also [[NTPd]] or [[OpenNTPD]]<br />
<br />
=== Updating DNS ===<br />
<br />
Active Directory is heavily dependent upon DNS. You will need to update {{ic|/etc/resolv.conf}} to use one or more of the Active Directory domain controllers:<br />
{{hc|/etc/resolv.conf|<br />
nameserver <IP1><br />
nameserver <IP2><br />
}}<br />
Replacing <IP1> and <IP2> with valid IP addresses for the AD servers. If your AD domains do not permit DNS forwarding or recursion, you may need to add additional resolvers. <br />
<br />
{{Note|If your machine dual boots Windows and Linux, you should use a different DNS hostname and netbios name for the linux configuration if both operating systems will be members of the same domain.}}<br />
<br />
=== Configuring NTP ===<br />
<br />
Read [[System time#Time synchronization]] to configure an NTP service.<br />
<br />
On the NTP servers configuration, use the IP addresses for the AD servers, as they typically run NTP as a service. Alternatively, you can use other known NTP servers provided the Active directory servers sync to the same stratum.<br />
<br />
Ensure that the service is configured to sync the time automatically very early on startup.<br />
<br />
=== Kerberos ===<br />
<br />
Let us assume that your AD is named example.com. Let us further assume your AD is ruled by two domain controllers, the primary and secondary one, which are named PDC and BDC, pdc.example.com and bdc.example.com respectively. Their IP adresses will be 192.168.1.2 and 192.168.1.3 in this example. Take care to watch your syntax; upper-case is very important here.<br />
<br />
{{hc|/etc/krb5.conf|<nowiki><br />
[libdefaults]<br />
default_realm = EXAMPLE.COM<br />
clockskew = 300<br />
ticket_lifetime = 1d<br />
forwardable = true<br />
proxiable = true<br />
dns_lookup_realm = true<br />
dns_lookup_kdc = true<br />
<br />
[realms]<br />
EXAMPLE.COM = {<br />
kdc = PDC.EXAMPLE.COM<br />
admin_server = PDC.EXAMPLE.COM<br />
default_domain = EXAMPLE.COM<br />
}<br />
<br />
[domain_realm]<br />
.kerberos.server = EXAMPLE.COM<br />
.example.com = EXAMPLE.COM<br />
example.com = EXAMPLE.COM<br />
example = EXAMPLE.COM<br />
<br />
[appdefaults]<br />
pam = {<br />
ticket_lifetime = 1d<br />
renew_lifetime = 1d<br />
forwardable = true<br />
proxiable = false<br />
retain_after_close = false<br />
minimum_uid = 0<br />
debug = false<br />
}<br />
<br />
[logging]<br />
default = FILE:/var/log/krb5libs.log<br />
kdc = FILE:/var/log/kdc.log<br />
admin_server = FILE:/var/log/kadmind.log<br />
</nowiki>}}<br />
<br />
{{Note|Heimdal 1.3.1 deprecated DES encryption which is required for AD authentication before Windows Server 2008. You will probably have to add {{bc|1=allow_weak_crypto = true}} to the {{Ic|[libdefaults]}} section.}}<br />
<br />
==== Creating a Kerberos ticket ====<br />
{{note|The keys and commands are user specific: sudo will be root, so your non-elevated account can connect to a different AD user with a separate key. If you only have one domain, it is not necessary to type @EXAMPLE.COM}}<br />
<br />
Now you can query the AD domain controllers and request a kerberos ticket ('''uppercase is necessary'''):<br />
{{bc|kinit administrator@EXAMPLE.COM}}<br />
<br />
You can use any username that has rights as a Domain Administrator.<br />
<br />
==== Validating the Ticket ====<br />
Run '''klist''' to verify you did receive the token. You should see something similar to:<br />
{{hc|# klist|<br />
Ticket cache: FILE:/tmp/krb5cc_0<br />
Default principal: administrator@EXAMPLE.COM<br />
<br />
Valid starting Expires Service principal <br />
02/04/12 21:27:47 02/05/12 07:27:42 krbtgt/EXAMPLE.COM@EXAMPLE.COM<br />
renew until 02/05/12 21:27:47<br />
}}<br />
<br />
=== pam_winbind.conf ===<br />
<br />
If you get errors stating that /etc/security/pam_winbind.conf was not found, create the file and add the following:<br />
<br />
{{hc|/etc/security/pam_winbind.conf|<nowiki><br />
[global]<br />
debug = no<br />
debug_state = no<br />
try_first_pass = yes<br />
krb5_auth = yes<br />
krb5_ccache_type = FILE<br />
cached_login = yes<br />
silent = no<br />
mkhomedir = yes<br />
</nowiki>}}<br />
<br />
With this setup, winbind will create user keytabs on the fly (krb5_ccache_type = FILE) at login and maintain them. You can verify this by simply running klist in a shell after logging in as an AD user but without needing to run kinit. You may need to set additional permissions on /etc/krb5.keytab eg 640 instead of 600 to get this to work (see {{Bug|52621}} for example)<br />
<br />
=== Samba ===<br />
Samba is a free software re-implementation of the SMB/CIFS networking protocol. It also includes tools for Linux machines to act as Windows networking servers and clients.<br />
<br />
{{Note|The configuration can vary greatly depending on how the Windows environment is deployed. Be prepared to troubleshoot and research}}<br />
<br />
In this section, we will focus on getting Authentication to work first by editing the 'Global' section first. Later, we will go back and add shares.<br />
<br />
{{hc|/etc/samba/smb.conf|<nowiki><br />
[Global]<br />
netbios name = MYARCHLINUX<br />
workgroup = EXAMPLE<br />
realm = EXAMPLE.COM<br />
server string = %h ArchLinux Host<br />
security = ads<br />
encrypt passwords = yes<br />
password server = pdc.example.com<br />
client signing = auto<br />
server signing = auto<br />
<br />
idmap config * : backend = tdb<br />
idmap config * : range = 10000-20000<br />
<br />
winbind use default domain = Yes<br />
winbind enum users = Yes<br />
winbind enum groups = Yes<br />
winbind nested groups = Yes<br />
winbind separator = +<br />
winbind refresh tickets = yes<br />
winbind offline logon = yes<br />
winbind cache time = 300<br />
<br />
template shell = /bin/bash<br />
template homedir = /home/%D/%U<br />
<br />
preferred master = no<br />
dns proxy = no<br />
wins server = pdc.example.com<br />
wins proxy = no<br />
<br />
inherit acls = Yes<br />
map acl inherit = Yes<br />
acl group control = yes<br />
<br />
load printers = no<br />
debug level = 3<br />
use sendfile = no<br />
</nowiki>}}<br />
<br />
=== Join the domain ===<br />
<br />
You need an AD Administrator account to do this. Let us assume this is named Administrator. The command is 'net ads join'<br />
{{hc|# net ads join -U Administrator|<br />
Administrator's password: xxx<br />
Using short domain name -- EXAMPLE<br />
Joined 'MYARCHLINUX' to realm 'EXAMPLE.COM'<br />
}}<br />
<br />
== Starting and testing services ==<br />
<br />
=== Starting Samba ===<br />
<br />
Hopefully, you have not rebooted yet! Fine. If you are in an X-session, quit it, so you can test login into another console, while you are still logged in.<br />
<br />
Enable and start the individual Samba daemons {{ic|smbd.service}}, {{ic|nmbd.service}}, and {{ic|winbindd.service}}.<br />
<br />
{{Note|In {{Pkg|samba}} 4.8.0-1, the Samba daemon units have been renamed from {{ic|smbd.service}}, {{ic|nmbd.service}}, and {{ic|winbindd.service}} to {{ic|smb.service}}, {{ic|nmb.service}}, and {{ic|winbind.service}}.}}<br />
<br />
Next we will need to modify the NSSwitch configuration, which tells the Linux host how to retrieve information from various sources and in which order to do so. In this case, we are appending Active Directory as additional sources for Users, Groups, and Hosts.<br />
<br />
{{hc|/etc/nsswitch.conf|<br />
passwd: files winbind<br />
shadow: files winbind<br />
group: files winbind <br />
<br />
hosts: files dns wins<br />
}}<br />
<br />
=== Testing Winbind ===<br />
Let us check if winbind is able to query the AD. The following command should return a list of AD users:<br />
<br />
{{hc|# wbinfo -u|<br />
administrator<br />
guest<br />
krbtgt<br />
test.user<br />
}}<br />
* Note we created an Active Directory user called 'test.user' on the domain controller<br />
<br />
We can do the same for AD groups:<br />
<br />
{{hc|# wbinfo -g|<br />
domain computers<br />
domain controllers<br />
schema admins<br />
enterprise admins<br />
cert publishers<br />
domain admins<br />
domain users<br />
domain guests<br />
group policy creator owners<br />
ras and ias servers<br />
allowed rodc password replication group<br />
denied rodc password replication group<br />
read-only domain controllers<br />
enterprise read-only domain controllers<br />
dnsadmins<br />
dnsupdateproxy<br />
}}<br />
<br />
=== Testing nsswitch ===<br />
<br />
To ensure that our host is able to query the domain for users and groups, we test nsswitch settings by issuing the 'getent' command.<br />
<br />
If user accounts from your DC are not showing, try adding the following line to your smb.conf file:<br />
{{hc|/etc/samba/smb.conf|<nowiki><br />
winbind trusted domains only = no<br />
</nowiki>}}<br />
<br />
The following output shows what a stock ArchLinux install looks like:<br />
<br />
{{hc|# getent passwd|<br />
root:x:0:0:root:/root:/bin/bash<br />
bin:x:1:1:bin:/bin:/bin/false<br />
daemon:x:2:2:daemon:/sbin:/bin/false<br />
mail:x:8:12:mail:/var/spool/mail:/bin/false<br />
ftp:x:14:11:ftp:/srv/ftp:/bin/false<br />
http:x:33:33:http:/srv/http:/bin/false<br />
nobody:x:99:99:nobody:/:/bin/false<br />
dbus:x:81:81:System message bus:/:/bin/false<br />
ntp:x:87:87:Network Time Protocol:/var/empty:/bin/false<br />
avahi:x:84:84:avahi:/:/bin/false<br />
administrator:*:10001:10006:Administrator:/home/EXAMPLE/administrator:/bin/bash<br />
guest:*:10002:10007:Guest:/home/EXAMPLE/guest:/bin/bash<br />
krbtgt:*:10003:10006:krbtgt:/home/EXAMPLE/krbtgt:/bin/bash<br />
test.user:*:10000:10006:Test User:/home/EXAMPLE/test.user:/bin/bash<br />
}}<br />
<br />
And for groups:<br />
{{hc|# getent group|<br />
root:x:0:root<br />
bin:x:1:root,bin,daemon<br />
daemon:x:2:root,bin,daemon<br />
sys:x:3:root,bin<br />
adm:x:4:root,daemon<br />
tty:x:5:<br />
disk:x:6:root<br />
lp:x:7:daemon<br />
mem:x:8:<br />
kmem:x:9:<br />
wheel:x:10:root<br />
ftp:x:11:<br />
mail:x:12:<br />
uucp:x:14:<br />
log:x:19:root<br />
utmp:x:20:<br />
locate:x:21:<br />
rfkill:x:24:<br />
smmsp:x:25:<br />
http:x:33:<br />
games:x:50:<br />
network:x:90:<br />
video:x:91:<br />
audio:x:92:<br />
optical:x:93:<br />
floppy:x:94:<br />
storage:x:95:<br />
scanner:x:96:<br />
power:x:98:<br />
nobody:x:99:<br />
users:x:100:<br />
dbus:x:81:<br />
ntp:x:87:<br />
avahi:x:84:<br />
domain computers:x:10008:<br />
domain controllers:x:10009:<br />
schema admins:x:10010:administrator<br />
enterprise admins:x:10011:administrator<br />
cert publishers:x:10012:<br />
domain admins:x:10013:test.user,administrator<br />
domain users:x:10006:<br />
domain guests:x:10007:<br />
group policy creator owners:x:10014:administrator<br />
ras and ias servers:x:10015:<br />
allowed rodc password replication group:x:10016:<br />
denied rodc password replication group:x:10017:krbtgt<br />
read-only domain controllers:x:10018:<br />
enterprise read-only domain controllers:x:10019:<br />
dnsadmins:x:10020:<br />
dnsupdateproxy:x:10021:<br />
}}<br />
<br />
=== Testing Samba commands ===<br />
<br />
Try out some net commands to see if Samba can communicate with AD:<br />
<br />
{{hc|# net ads info|<nowiki><br />
[2012/02/05 20:21:36.473559, 0] param/loadparm.c:7599(lp_do_parameter)<br />
Ignoring unknown parameter "idmapd backend"<br />
LDAP server: 192.168.1.2<br />
LDAP server name: PDC.example.com<br />
Realm: EXAMPLE.COM<br />
Bind Path: dc=EXAMPLE,dc=COM<br />
LDAP port: 389<br />
Server time: Sun, 05 Feb 2012 20:21:33 CST<br />
KDC server: 192.168.1.2<br />
Server time offset: -3<br />
</nowiki>}}<br />
<br />
{{hc|# net ads lookup|<br />
[2012/02/05 20:22:39.298823, 0] param/loadparm.c:7599(lp_do_parameter)<br />
Ignoring unknown parameter "idmapd backend"<br />
Information for Domain Controller: 192.168.1.2<br />
<br />
Response Type: LOGON_SAM_LOGON_RESPONSE_EX<br />
GUID: 2a098512-4c9f-4fe4-ac22-8f9231fabbad<br />
Flags:<br />
Is a PDC: yes<br />
Is a GC of the forest: yes<br />
Is an LDAP server: yes<br />
Supports DS: yes<br />
Is running a KDC: yes<br />
Is running time services: yes<br />
Is the closest DC: yes<br />
Is writable: yes<br />
Has a hardware clock: yes<br />
Is a non-domain NC serviced by LDAP server: no<br />
Is NT6 DC that has some secrets: no<br />
Is NT6 DC that has all secrets: yes<br />
Forest: example.com<br />
Domain: example.com<br />
Domain Controller: PDC.example.com<br />
Pre-Win2k Domain: EXAMPLE<br />
Pre-Win2k Hostname: PDC<br />
Server Site Name : Office<br />
Client Site Name : Office<br />
NT Version: 5<br />
LMNT Token: ffff<br />
LM20 Token: ffff<br />
}}<br />
<br />
{{hc|<nowiki># net ads status -U administrator%password | less</nowiki>|<nowiki><br />
objectClass: top<br />
objectClass: person<br />
objectClass: organizationalPerson<br />
objectClass: user<br />
objectClass: computer<br />
cn: myarchlinux<br />
distinguishedName: CN=myarchlinux,CN=Computers,DC=leafscale,DC=inc<br />
instanceType: 4<br />
whenCreated: 20120206043413.0Z<br />
whenChanged: 20120206043414.0Z<br />
uSNCreated: 16556<br />
uSNChanged: 16563<br />
name: myarchlinux<br />
objectGUID: 2c24029c-8422-42b2-83b3-a255b9cb41b3<br />
userAccountControl: 69632<br />
badPwdCount: 0<br />
codePage: 0<br />
countryCode: 0<br />
badPasswordTime: 0<br />
lastLogoff: 0<br />
lastLogon: 129729780312632000<br />
localPolicyFlags: 0<br />
pwdLastSet: 129729764538848000<br />
primaryGroupID: 515<br />
objectSid: S-1-5-21-719106045-3766251393-3909931865-1105<br />
...<snip>...<br />
</nowiki>}}<br />
<br />
== Configuring PAM ==<br />
<br />
Now we will change various rules in PAM to allow Active Directory users to use the system for things like login and sudo access. When changing the rules, note the order of these items and whether they are marked as '''required''' or '''sufficient''' is critical to things working as expected. You should not deviate from these rules unless you know how to write PAM rules.<br />
<br />
In case of logins, PAM should first ask for AD accounts, and for local accounts if no matching AD account was found. Therefore, we add entries to include {{ic|pam_winbind.so}} into the authentication process.<br />
<br />
The Arch Linux PAM configuration keeps the central auth process in {{ic|/etc/pam.d/system-auth}}. Starting with the stock configuration from {{ic|pambase}}, change it like this:<br />
<br />
=== system-auth ===<br />
<br />
==== "auth" section ====<br />
<br />
Find the line:<br />
<br />
auth required pam_unix.so ...<br />
<br />
Delete it, and replace with:<br />
<br />
auth [success=1 default=ignore] pam_localuser.so<br />
auth [success=2 default=die] pam_winbind.so<br />
auth [success=1 default=die] pam_unix.so nullok<br />
auth requisite pam_deny.so<br />
<br />
==== "account" section ====<br />
<br />
Find the line:<br />
<br />
account required pam_unix.so<br />
<br />
Keep it, and add this below:<br />
<br />
account [success=1 default=ignore] pam_localuser.so<br />
account required pam_winbind.so<br />
<br />
==== "password" section ====<br />
<br />
Find the line:<br />
<br />
password required pam_unix.so ...<br />
<br />
Delete it, and replace with:<br />
<br />
password [success=1 default=ignore] pam_localuser.so<br />
password [success=2 default=die] pam_winbind.so<br />
password [success=1 default=die] pam_unix.so sha512 shadow<br />
password requisite pam_deny.so<br />
<br />
==== "session" section ====<br />
<br />
Find the line:<br />
<br />
session required pam_unix.so<br />
<br />
Keep it, and add this line immediately above it:<br />
<br />
session required pam_mkhomedir.so skel=/etc/skel/ umask=0022<br />
<br />
Below the pam_unix line, add these:<br />
<br />
session [success=1 default=ignore] pam_localuser.so<br />
session required pam_winbind.so<br />
<br />
=== passwd ===<br />
<br />
==== "password" section ====<br />
<br />
In order for logged-in Active Directory users to be able to change their passwords with the 'passwd' command, the file {{ic|/etc/pam.d/passwd}} must include the information from system-auth.<br />
<br />
Find the line:<br />
<br />
password required pam_unix.so sha512 shadow nullok<br />
<br />
Delete it, and replace with:<br />
<br />
password include system-auth<br />
<br />
=== Testing login ===<br />
<br />
Now, start a new console session (or ssh) and try to login using the AD credentials. The domain name is optional, as this was set in the Winbind configuration as 'default realm'. Please note that in the case of ssh, you will need to modify the {{ic|/etc/ssh/sshd_config}} file to allow kerberos authentication {{ic|(KerberosAuthentication yes)}}.<br />
<br />
{{bc|<br />
test.user<br />
EXAMPLE+test.user<br />
}}<br />
<br />
Both should work. You should notice that {{ic|/home/example/test.user}} will be automatically created.<br />
'''Log into another session using an linux account. Check that you still be able to log in as root - but keep in mind to be logged in as root in at least one session!'''<br />
<br />
== Configuring Shares ==<br />
Earlier we skipped configuration of the shares. Now that things are working, go back to {{ic|/etc/samba/smb.conf}}, and add the exports for the host that you want available on the windows network. <br />
<br />
{{hc|/etc/samba/smb.conf|<nowiki><br />
[MyShare]<br />
comment = Example Share<br />
path = /srv/exports/myshare<br />
read only = no<br />
browseable = yes<br />
valid users = @NETWORK+"Domain Admins" NETWORK+test.user<br />
</nowiki>}}<br />
<br />
In the above example, the keyword '''NETWORK''' is to be used. Do not mistakenly substitute this with your domain name. For adding groups, prepend the '@' symbol to the group. Note that {{ic|Domain Admins}} is encapsulated in quotes so Samba correctly parses it when reading the configuration file.<br />
<br />
== Adding a machine keytab file and activating password-free kerberized ssh to the machine ==<br />
This explains how to generate a machine keytab file which you will need e.g. to enable password-free kerberized ssh to your machine from other machines in the domain. The scenario in mind is that you have a bunch of systems in your domain and you just added a server/workstation using the above description to your domain onto which a lot of users need to ssh in order to work - e.g. GPU workstation or an OpenMP compute node, etc. In this case you might not want to type your password every time you log in. On the other hand the key authentication used by many users in this case can not give you the necessary credentials to e.g. mount kerberized NFSv4 shares. So this will help you to enable password-free logins from your clients to the machine in question using kerberos ticket forwarding.<br />
<br />
=== Creating a machine key tab file ===<br />
run 'net ads keytab create -U administrator' as root to create a machine keytab file in /etc/krb5.keytab. It will prompt you with a warning that we need to enable keytab authentication in our configuration file, so we will do that in the next step. In my case it had problems when a key tab file is already in place - the command just did not come back it hang ... In that case you should rename the existing /etc/krb5.keytab and run the command again - it should work now.<br />
<br />
{{bc|# net ads keytab create -U administrator}}<br />
<br />
verify the content of your keytab by running:<br />
<br />
{{hc|# klist -k /etc/krb5.keytab|<nowiki><br />
Keytab name: FILE:/etc/krb5.keytab<br />
KVNO Principal<br />
---- --------------------------------------------------------------------------<br />
4 host/myarchlinux.example.com@EXAMPLE.COM<br />
4 host/myarchlinux.example.com@EXAMPLE.COM<br />
4 host/myarchlinux.example.com@EXAMPLE.COM<br />
4 host/myarchlinux.example.com@EXAMPLE.COM<br />
4 host/myarchlinux.example.com@EXAMPLE.COM<br />
4 host/MYARCHLINUX@EXAMPLE.COM<br />
4 host/MYARCHLINUX@EXAMPLE.COM<br />
4 host/MYARCHLINUX@EXAMPLE.COM<br />
4 host/MYARCHLINUX@EXAMPLE.COM<br />
4 host/MYARCHLINUX@EXAMPLE.COM<br />
4 MYARCHLINUX$@EXAMPLE.COM<br />
4 MYARCHLINUX$@EXAMPLE.COM<br />
4 MYARCHLINUX$@EXAMPLE.COM<br />
4 MYARCHLINUX$@EXAMPLE.COM<br />
4 MYARCHLINUX$@EXAMPLE.COM<br />
</nowiki>}}<br />
<br />
=== Enabling keytab authentication ===<br />
Now you need to tell winbind to use the file by adding these lines to the /etc/samba/smb.conf:<br />
<br />
kerberos method = secrets and keytab<br />
dedicated keytab file = /etc/krb5.keytab<br />
<br />
It should look something like this:<br />
<br />
{{hc|/etc/samba/smb.conf|<nowiki><br />
[Global]<br />
netbios name = MYARCHLINUX<br />
workgroup = EXAMPLE<br />
realm = EXAMPLE.COM<br />
server string = %h ArchLinux Host<br />
security = ads<br />
encrypt passwords = yes<br />
password server = pdc.example.com<br />
kerberos method = secrets and keytab<br />
dedicated keytab file = /etc/krb5.keytab<br />
<br />
idmap config * : backend = tdb<br />
idmap config * : range = 10000-20000<br />
<br />
winbind use default domain = Yes<br />
winbind enum users = Yes<br />
winbind enum groups = Yes<br />
winbind nested groups = Yes<br />
winbind separator = +<br />
winbind refresh tickets = yes<br />
<br />
template shell = /bin/bash<br />
template homedir = /home/%D/%U<br />
<br />
preferred master = no<br />
dns proxy = no<br />
wins server = pdc.example.com<br />
wins proxy = no<br />
<br />
inherit acls = Yes<br />
map acl inherit = Yes<br />
acl group control = yes<br />
<br />
load printers = no<br />
debug level = 3<br />
use sendfile = no<br />
</nowiki>}}<br />
<br />
Restart the winbind daemon using 'systemctl restart winbindd.service' with root privileges.<br />
<br />
{{bc|# systemctl restart winbindd.service}}<br />
<br />
Check if everything works by getting a machine ticket for your system by running <br />
<br />
{{bc|# kinit MYARCHLINUX$ -kt /etc/krb5.keytab}}<br />
<br />
This should not give you any feedback but running 'klist' should show you sth like:<br />
<br />
{{hc|# klist|<br />
Ticket cache: FILE:/tmp/krb5cc_0<br />
Default principal: MYARCHLINUX$@EXAMPLE.COM<br />
<br />
Valid starting Expires Service principal <br />
02/04/12 21:27:47 02/05/12 07:27:42 krbtgt/EXAMPLE.COM@EXAMPLE.COM<br />
renew until 02/05/12 21:27:47<br />
}}<br />
<br />
Some common mistakes here are a) forgetting the trailing $ or b) ignoring case sensitivity - it needs to look exactly like the entry in the keytab (usually you cannot to much wrong with all capital)<br />
<br />
=== Preparing sshd on server ===<br />
<br />
All we need to do is add some options to our sshd_config and restart the sshd.service.<br />
<br />
Edit /etc/ssh/sshd_config to look like this in the appropriate places:<br />
<br />
{{hc|# /etc/ssh/sshd_config|<br />
<br />
...<br />
<br />
# Change to no to disable s/key passwords<br />
ChallengeResponseAuthentication no<br />
<br />
# Kerberos options<br />
KerberosAuthentication yes<br />
#KerberosOrLocalPasswd yes<br />
KerberosTicketCleanup yes<br />
KerberosGetAFSToken yes<br />
<br />
# GSSAPI options<br />
GSSAPIAuthentication yes<br />
GSSAPICleanupCredentials yes<br />
<br />
...<br />
<br />
}}<br />
<br />
Restart the sshd.service using:<br />
<br />
{{bc|# systemctl restart sshd.service}}<br />
<br />
=== Adding necessary options on client ===<br />
<br />
First we need to make sure that the tickets on our client are forwardable. This is usually standard but we better check anyways. You have to look for the forwardable option and set it to 'true' in the Kerberos config file /etc/krb5.conf<br />
<br />
{{bc|<nowiki>forwardable = true</nowiki>}}<br />
<br />
Secondly we need to add the options <br />
<br />
GSSAPIAuthentication yes<br />
GSSAPIDelegateCredentials yes<br />
<br />
to our .ssh/config file to tell ssh to use this options - alternatively they can be invoked using the -o options directly in the ssh command (see 'man ssh' for help).<br />
<br />
=== Testing the setup ===<br />
On Client:<br />
<br />
make sure you have a valid ticket - if in doubt run 'kinit'<br />
<br />
then use ssh to connect to you machine<br />
<br />
{{bc|ssh myarchlinux.example.com }}<br />
<br />
you should get connected without needing to enter your password.<br />
<br />
if you have key authentication additionally activated then you should perform<br />
<br />
{{bc|ssh -v myarchlinux.example.com }}<br />
<br />
to see which authentication method it actually uses.<br />
<br />
For debugging you can enable DEBUG3 on the server and look into the journal using [[journalctl]].<br />
<br />
=== Nifty fine-tuning for complete password-free kerberos handling. ===<br />
<br />
In case your clients are not using domain accounts on their local machines (for whatever reason) it can be hard to actually teach them to kinit before ssh to the workstation. Therefore I came up with a nice workaround:<br />
<br />
== Generating user Keytabs which are accepted by AD ==<br />
<br />
On a system let the user run:<br />
<br />
{{bc|<nowiki><br />
ktutil<br />
addent -password -p username@EXAMPLE.COM -k 1 -e RC4-HMAC<br />
- enter password for username -<br />
wkt username.keytab<br />
q<br />
</nowiki>}}<br />
<br />
Now test the file by invoking:<br />
<br />
{{bc|kinit username@EXAMPLE.COM -kt username.keytab}}<br />
<br />
It should not promt you to give your password nor should it give any other feedback. If it worked you are basically done - just put the line above into your ~./bashrc - you can now get kerberos tickets without typing a password and with that you can connect to your workstation without typing a password while being completely kerberized and able to authenticate against NFSv4 and CIFS via tickets - pretty neat.<br />
<br />
=== Nice to know ===<br />
<br />
The file 'username.keytab' is not machinespecific and can therefore be copied around. E.g. we created the files on a linux machine and copied them to our Mac clients as the commands on Macs are different ...<br />
<br />
== See also ==<br />
<br />
* [[wikipedia:Active_Directory|Wikipedia - Active Directory]]<br />
* [[wikipedia:Samba_(software)|Wikipedia - Samba]]<br />
* [[wikipedia:Kerberos_(protocol)|Wikipedia - Kerberos]]<br />
* [http://www.samba.org/samba/docs Samba - Documentation]<br />
* [http://wiki.samba.org/index.php/Samba_&_Active_Directory Samba Wiki - Samba & Active Directory]<br />
* [http://www.samba.org/samba/docs/man/manpages-3/smb.conf.5.html {{ic|smb.conf(5)}} manpage]<br />
=== Commercial Solutions ===<br />
* Centrify<br />
* Likewise<br />
<br />
==== OpenSource version ===<br />
* [https://github.com/BeyondTrust/pbis-open/ PowerBroker Identity Services Open]: formerly Likewise acquired by BeyondTrust<br />
* [https://www.centrify.com/express/linux/ Centrify Express for Linux]</div>Twnainghttps://wiki.archlinux.org/index.php?title=Talk:Systemd&diff=563072Talk:Systemd2019-01-13T08:58:40Z<p>Twnaing: /* Add more detail about DynamicUser */ new section</p>
<hr />
<div>== Should the section "writing a custom .service" be expanded? ==<br />
<br />
I think so.. as long as I got, this is necessary to run self-made scripts during the boot process, but this is not clear and the structure of the files is not well presented.<br />
<br />
Moreover, when explain how to transit from the initscript, some referrals on how to move the old custom hooks in {{ic|/etc/rc.d/functions.d}} to be executed by systemd, should be made.<br><br />
-- [[User:DarioP|DarioP]] ([[User talk:DarioP|talk]]) 12:42, 18 November 2012 (UTC)<br />
<br />
:I think it needs to be expanded indeed. As a newbie, it is easy to grasp the concept of "put your code in rc.local", and it's not clear how to transition. Specific questions, as also mentioned by DarioP: In what directory should I place my service definition? On the examples page, there are some files named with an at-sign ({{ic|@}}), what difference does that make? It would be very helpful to have a complete example for running a single command at boot (my example: {{ic|echo noop > /sys/block/sdb/queue/scheduler}}).<br />
:-- [[User:Fa2k|Fa2k]] ([[User talk:Fa2k|talk]]) 3 February 2013<br />
<br />
::I third this motion, I had no idea what I was doing the whole time I was translating a service file. I happened to run accross this stackoverflow post that helped a lot: https://unix.stackexchange.com/questions/47695/how-to-write-startup-script-for-systemd - but I'm going to also add some edits to the section to help save other people time. <br />
::--[[User:T.ink.er|T.ink.er]] ([[User talk:T.ink.er|talk]]) 00:42, 7 July 2014 (UTC)<br />
<br />
:::There's actually no template in the Wiki for a basic ''.service'' file. --'''<span style="text-shadow:grey 0.1em 0.1em 0.1em; font-size:110%">[[User:Det|<span style="color:gold">D</span><span style="color:orange">e</span><span style="color:red">t</span>]][[User talk:Det|<sup><font color="white">talk</font></sup>]]</span>''' 12:54, 23 July 2015 (UTC)<br />
<br />
::::What is a "basic" service file anyway? Since {{ic|systemd.service(5)}} contains an entire section with examples, I think that we can leave it that way. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 15:35, 23 July 2015 (UTC)<br />
<br />
:::::The [http://0pointer.de/public/systemd-man/systemd.service.html#Examples Example 1. Simple service] in there ({{ic|Description}}/{{ic|ExecStart}}/{{ic|WantedBy}}, where each would be explained). If we're just going to leave that to a manpage or copying a "finished" ''.service'', the link should at least be moved to the top of the section from under [[Systemd#Service types|#Service types]]. I'd still be in favor of directly linking to the examples section. --'''<span style="text-shadow:grey 0.1em 0.1em 0.1em; font-size:110%">[[User:Det|<span style="color:gold">D</span><span style="color:orange">e</span><span style="color:red">t</span>]][[User talk:Det|<sup><font color="white">talk</font></sup>]]</span>''' 06:37, 24 July 2015 (UTC)<br />
<br />
::::::Good idea. That manpage itself is so huge, it sure is helpful to point to the example section explicitly. Added an earlier-on link to it with [https://wiki.archlinux.org/index.php?title=Systemd&type=revision&diff=387706&oldid=387219]. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 22:21, 24 July 2015 (UTC)<br />
<br />
:::::::Very nice. What about that second mention under [[systemd#Service types|#Service types]]? It starts sounding kind of "duh". --'''<span style="text-shadow:grey 0.1em 0.1em 0.1em; font-size:110%">[[User:Det|<span style="color:gold">D</span><span style="color:orange">e</span><span style="color:red">t</span>]][[User talk:Det|<sup><font color="white">talk</font></sup>]]</span>''' 22:30, 24 July 2015 (UTC)<br />
<br />
::::::::I've added a link also to the second section, or have you had something more radical in mind? -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 09:36, 25 July 2015 (UTC)<br />
<br />
:::::::::No, I meant why need a man mention there at all? Isn't it obvious from the link in the intro that all the sub-section details are also located there? --'''<span style="text-shadow:grey 0.1em 0.1em 0.1em; font-size:110%">[[User:Det|<span style="color:gold">D</span><span style="color:orange">e</span><span style="color:red">t</span>]][[User talk:Det|<sup><font color="white">talk</font></sup>]]</span>''' 21:12, 26 July 2015 (UTC)<br />
<br />
::::::::::Ok, yes. Could do without. Though the last man reference is way up in another section and ending a section with a bullet always looks incomplete for my reading habit. Then ending a topic with a man reference also implies "That's all we got here and the next section is another topic". So it's a bit of a phrase, but has a good didactic purpose in my view. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 09:16, 27 July 2015 (UTC)<br />
<br />
:::::::::::I agree on systemic references to the manuals. Where possible, wiki pages should introduce to the upstream documentation. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 13:48, 27 July 2015 (UTC)<br />
<br />
::::::::::::Oh, it links to [http://www.freedesktop.org/software/systemd/man/systemd.service.html#Type= #Type]. Shouldn't it at least talk about the ''type section'' like the one in the [[systemd#Writing unit files|intro]]? --'''<span style="text-shadow:grey 0.1em 0.1em 0.1em; font-size:110%">[[User:Det|<span style="color:gold">D</span><span style="color:orange">e</span><span style="color:red">t</span>]][[User talk:Det|<sup><font color="white">talk</font></sup>]]</span>''' 00:38, 28 July 2015 (UTC)<br />
<br />
:::::::::::::The Service Types section is certainly a good comprehensive overview of the options available when writing a unit file but it may help those newer to systemd if we highlighted a little more why 'simple' is the default and that they will likely only need that option, 'oneshot' or possibly 'forking' at least to get started. Perhaps expanding on 'forking' that it is specifically for launching services that background themselves (i.e. where the parent launches a child process and terminates) might be helpful too. Table 8.10 under [https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/System_Administrators_Guide/sect-Managing_Services_with_systemd-Unit_Files.html#sect-Managing_Services_with_systemd-Unit_File_Structure this section of the RedHat portal] could also be a useful addition. [[User:Kal|Kal]] ([[User talk:Kal|talk]]) 22:01, 9 December 2015 (UTC)<br />
<br />
== Systemd defaults / to rshared, gotcha ==<br />
<br />
Still reading up on this, so I'm not 100% solid but I discovered during the systemd transition that it defaults the / mount to rshared (see [http://www.kernel.org/doc/Documentation/filesystems/sharedsubtree.txt Shared subtree] for definitions). Excerpted from core/mount-setup.c in systemd github: {{bc|/* Mark the root directory as shared in regards to mount<br />
* propagation. The kernel defaults to "private", but we think<br />
* it makes more sense to have a default of "shared" so that<br />
* nspawn and the container tools work out of the box. If<br />
* specific setups need other settings they can reset the<br />
* propagation mode to private if needed. */<br />
if (detect_container(NULL) <&#61; 0)<br />
if (mount(NULL, "/", NULL, MS_REC&#124;MS_SHARED, NULL) < 0)<br />
log_warning("Failed to set up the root directory for shared mount propagation: %m");}}<br />
This means that all bind mounts made through fstab will default to shared behavior, not private. For those users who depend on non-recursive bind mounts, this can be a very big gotcha (as the mount propagation effectively nullifies the non-recursion).<br />
I think it should be at least noted under Filesystem Mounts, since fstab bind entries definitely may not preserve behavior across the systemd transition and there are definitely some systems that would fail to start up/operate properly due to this, perhaps even silently.<br />
<br />
As a side note, for nested bind mounts this also results in multiplicative bloat of the mount table, depending on what kind of nesting structure<br />
is used (it's actually relatively easy to construct a nesting sequence that makes 2^n mounts out of n mount calls).<br />
<br />
Still looking into good (and easy) configuration solutions.<br />
<br />
[[User:Compgamer89|Compgamer89]] ([[User talk:Compgamer89|talk]]) 07:16, 4 December 2012 (UTC)<br />
<br />
:You may find [http://cgit.freedesktop.org/systemd/systemd/commit/?id=b3ac5f8cb98757416d8660023d6564a7c411f0a0 this commit] useful. --[[User:David Strauss|David Strauss]] ([[User talk:David Strauss|talk]]) 22:58, 13 December 2012 (UTC)<br />
<br />
== Make section "Targets" more clearly ==<br />
<br />
In general, the introductory paragraph does not explain the concept enough (it seems like one sentence is missing explaning what a target ''is'').<br />
<br />
Then there are some occurences of words (first in the article) which might confuse unexperienced users:<br />
* "runlevel" - Link to Wikipedia?<br />
* In subsection "Create custom target" ''Fedora'' is mentioned: "The runlevels that are assigned a specific purpose on vanilla Fedora installs"; This adds confusion to the first point.<br />
<br />
[[User:Xry|Xry]] ([[User talk:Xry|talk]]) 16:06, 9 September 2015 (UTC)<br />
<br />
== Section "Writing unit files" does not distinguish between overrides and new files ==<br />
<br />
If you want to override a unit, create /etc/systemd/<unit>.service.d/override.conf. (.d directories are for overriding a unit.)<br />
A new service created as override will *not* be found by systemctl daemon-reload!<br />
(Not knowing this did cost me some hours of frustration.)<br />
Instead if you want to add a new service, you need it to go straight into /etc/systemd/system.<br />
After systemctl daemon-reload you can do systemctl enable <service> or systemctl start <service>.<br />
<br />
{{unsigned|17:48, 30 November 2015|Bwe}}<br />
<br />
:And which part of [[Systemd#Writing_unit_files]] is inaccurate? [[Systemd#Editing_provided_unit_files]] says (emphasis mine):<br />
::There are two ways to edit a unit file provided by a package: replace the entire unit file '''with a new one''' or create drop-in snippets which are applied '''on top of the existing unit file'''.<br />
:-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 19:08, 30 November 2015 (UTC)<br />
<br />
:Nowhere in that section does it claim that a new service will be created for the override. I've tweaked the language a little bit to emphasize that both methods edit the original unit, even when you create a new file. [[User:Silverhammermba|Silverhammermba]] ([[User talk:Silverhammermba|talk]]) 16:45, 1 December 2015 (UTC)<br />
<br />
<br />
==Subsection "dependent services are not started when starting a service manually"==<br />
<br />
As far as I know the systemd behaviour for dependent services is a design ... decision (I'd call it a design error, but that's just me). Thus I documented the nonintuitive behaviour in the wiki instead of reporting it as bug.<br />
<br />
Maybe the unit file for libvirtd is not correct and needs additional Wants/Requires lines. If that solves the problem, I'll update the entry and place it as clarification for writing own systemd unit files. Until then I'd suggest to keep the entry as it is.<br />
<br />
{{unsigned|09:01, 19 May 2016|Vtanger}}<br />
<br />
:As per [[Libvirt#Daemon]] for a manual start of libvird, you should also start {{ic|virtlogd.service}}. It may be non-intuitive, but have a reason upstream split it like that. Personally, I think upstream should package an alternative {{ic|libvirtd.socket}} unit which starts all requires. See also [https://bugzilla.redhat.com/show_bug.cgi?id=1290357 redhat bug] '''I''' find it non-intuitive if a .service automatically starts a socket by itself. I'd rather control such myself. <br />
:In any case it seems the wrong example for the [[systemd]] article because of existing [[Libvirt#Daemon]] instructions in my view. <br />
:. You still disagree? --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 10:17, 19 May 2016 (UTC)<br />
<br />
== Removal consideration: Sandboxing application environments ==<br />
There has been systemd upstream talk: [https://lwn.net/Articles/709759/ LWN: CVE-2016-8655] and [https://lwn.net/Articles/709755/ LWN: Re: CVE-2016-8655]. Poettering discusses the same [http://0pointer.net/blog/avoiding-cve-2016-8655-with-systemd.html here]. I was considering dropping this section into [[Security]] but deferred to the ''tips and tricks'' section here. If the concern is that the content is not officially enabled upstream, the counterargument is that 1. the directives used in the sandbox are provided by official systemd upstream documentation 2. the unbound.service file is an Arch-specific creation. The new [[OpenVPN]] unit files are using environment directives, but those are provided by OpenVPN upstream. I see the section as a ''tip'' which attempts to improve upon defaults that could be of benefit to others (particularly those with long-running, network-bound services). But I am not opposed to it being moved to [[Security]] or under a more appropriate sub here (preferred). Thoughts? -- [[User:Adamlau|Adamlau]] ([[User talk:Adamlau|talk]]) 06:41, 18 January 2017 (UTC)<br />
<br />
:File a bug against the {{Pkg|unbound}} package then? An updated service can then be linked to from here as illustration of the various directives. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 07:23, 18 January 2017 (UTC)<br />
<br />
::Updated service would be neat, yes. Yet, it would miss the verbose. How about moving it to [[Capabilities]] and crosslink back? That article only has utterly simple examples so far. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 20:20, 19 January 2017 (UTC)<br />
<br />
:::I was thinking on keeping the explanations, but not the code block, because more users would benefit from an updated service (at least downstream in Arch) than a diff copied in this article. I'm not sure if the scope fits within [[Capabilities]], but I leave that up to you guys. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 20:30, 19 January 2017 (UTC)<br />
<br />
::::Relocating to [[Capabilities]] will work so long as the example provides additional focus with respect to the capability directive. systemd unit files are able to provide breadth of isolation mechanisms including namespaces, overlays and seccomp. Though Unbound is but one example, I plan to add a few more including hardened unit files for dhcpcd and nftables. Figuring out where unit file sandboxing discussion should go is up to you two. I figure that its proper location within the Wiki will become clearer as the topic is expanded upon. Move it to where you will and I will follow :) -- [[User:Adamlau|Adamlau]] ([[User talk:Adamlau|talk]]) 03:50, 20 January 2017 (UTC)<br />
<br />
:::::You noting you want to add further examples, made me come up with an even different approach: <br />
:::::# I moved the example to [[Unbound#Sandboxing]]. Note I left the remove template for the unit itself in, please consider adding a FS# for it.[https://wiki.archlinux.org/index.php?title=Unbound&type=revision&diff=465991&oldid=465990]<br />
:::::# I initialized a bullet list in [[Systemd#Sandboxing application environments]] [https://wiki.archlinux.org/index.php?title=Systemd&type=revision&diff=465996&oldid=465708]. This could be gradually expanded, be it for restricting capabilities or other related systemd features, or pinpoint also individual options (e.g. {{ic|1=ProtectSystem=strict}}).<br />
:::::What's going amiss is expanding [[capabilities]] itself a little. For {{ic|1=CapabilityBoundingSet=}} it seems more useful to to have it here really on second thought. Yet, we don't want to duplicate elaborations on capabilities themselves like you do in explaining the unbound example. Perhaps shorten it and reference capabilities(7)? <br />
:::::What do you two think about this approach? --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 19:07, 20 January 2017 (UTC)<br />
::::::Sounds good to me. I'll rework an example for [[capabilities]] and expand it accordingly. -- [[User:Adamlau|Adamlau]] ([[User talk:Adamlau|talk]]) 04:35, 23 January 2017 (UTC)<br />
<br />
== dependency to network being online ==<br />
Can we have a working example for the typical case one needs network to be up and running before executing the service?<br />
it says about network.target but I don't think the network is online at this stage.<br />
<br />
Reading systemd manual: waiting for network-online.target and enabling NetworkManager-wait-online.service for the ones using networkmanager may do the trick but i read this delays the boot<br />
<br />
[[User:Kewl|Kewl]] ([[User talk:Kewl|talk]]) 09:31, 18 November 2017 (UTC)<br />
<br />
:No, because it depends on which network manager the user has. Basically all working examples are [https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/ here]. Obviously, the {{ic|NetworkManager-wait-online.service}} delays the boot because some services can be started only after the network connection has been established. But hey, that's what you wanted ;-) [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 03:48, 19 November 2017 (UTC)<br />
<br />
::let's say I missed my cloud backup and the systemd timer triggers the cloud backup service at startup, I don't want to delay the boot waiting for my backup to finish, just the backup service should wait for the network to be up. The manual is nice but it is two pages of talk, Arch wiki gets to the point and "cuts the crap" ;) [[User:Kewl|Kewl]] ([[User talk:Kewl|talk]]) 08:27, 19 November 2017 (UTC)<br />
<br />
:::Have you actually had the problem or is it just a speculation based on reading these ''talks''? -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 14:51, 19 November 2017 (UTC)<br />
<br />
::::'''network-online.target''' seems to work for me without the need to mess up with networkmanager but I haven't done a proper study yet of what is happening [[User:Kewl|Kewl]] ([[User talk:Kewl|talk]]) 17:42, 19 November 2017 (UTC)<br />
<br />
== systemctl help unit really needed?! ==<br />
<br />
Do we really need to put ''systemctl help unit'' in '''Using Units''' section?<br />
<br />
Because:<br />
<br />
# I have never seen someone point this out or actually use this option.<br />
# Systemd guys probably named it wrong. "systemctl manual" would be more appropriate name. People normally would expect that "systemctl help" would give help related to systemctl command itself. (just like "ip help add")<br />
# Example of daemon-reload should go above it as it is used more frequently.<br />
<br />
--[[User:Amish|Amish]] ([[User talk:Amish|talk]]) 05:07, 24 June 2018 (UTC)<br />
<br />
== vim-systemd is gone? ==<br />
<br />
In the section "Editing Provided Units" the {{Pkg|vim-systemd}} package is mentioned. However, on 2018-10-11 that's not an actual package in either official or AUR repositories. Was it deleted? Should that reference be gone as well?<br />
:Yeah, it was just a vim syntax file. It's included with the main vim package now. [[User:Chowbok|Chowbok]] ([[User talk:Chowbok|talk]]) 04:52, 12 October 2018 (UTC)<br />
<br />
== Location of systemd unit files made by the system administrator ==<br />
<br />
This is related to the deletion of my edit about systemd unit files location. The section I modified was about "Writing Unit Files". So, as far as I understand, this includes both files written for packages and files written for local use only. So I don't understand why someone removed my edit. See the following for a deeper explanation of where systemd unit files written by the administrator should be located.<br />
<br />
{{ic|https://unix.stackexchange.com/questions/224992/where-do-i-put-my-systemd-unit-file}}<br />
<br />
PS: If the argument for the deletion of my edit is valid, shouldn't {{ic|/etc/systemd/system}} be removed too ?<br />
<br />
{{Unsigned|10:54, 27 December 2018 (UTC)|Apollo22}}<br />
<br />
:The [https://jlk.fjfi.cvut.cz/arch/manpages/man/systemd.unit.5#UNIT_FILE_LOAD_PATH systemd man page] says that {{ic|/usr/local/lib/systemd/system}} is for "units of installed packages". Hence, units should be created here by the installer when you install the package, not manually by the administrator. If you write a unit "for a package" rather than "for local use only", you should write it in the directory with the source code so that it is installed along with the package.<br />
:As for the file system hierarchy, note that systemd has its own version (see {{man|7|file-hierarchy}}) and {{ic|/usr/local/}} is not mentioned there.<br />
:-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 11:16, 27 December 2018 (UTC)<br />
<br />
== Add more detail about DynamicUser ==<br />
<br />
DynamicUser has been used in packages and I found no discussion about it in this page.<br />
<br />
I learnt a lot from this blog post http://0pointer.net/blog/dynamic-users-with-systemd.html</div>Twnainghttps://wiki.archlinux.org/index.php?title=User:Twnaing/Xiki&diff=541574User:Twnaing/Xiki2018-09-16T14:04:50Z<p>Twnaing: initial information</p>
<hr />
<div>[http://xiki.org Xiki] makes the shell console more friendly and powerful.<br />
<br />
Its features include<br />
<br />
* Expand commands<br />
* Shell + GUI<br />
* Run in your text editor<br />
<br />
Checkout the [http://xiki.org/screencasts/ screencast] to see Xiki in action<br />
<br />
== Installation ==<br />
<br />
Install it with the following one line command.<br />
<br />
<code>curl -L https://xiki.com/install_xsh -o ~/install_xsh; bash ~/install_xsh</code></div>Twnainghttps://wiki.archlinux.org/index.php?title=IPMI&diff=494288IPMI2017-10-29T12:06:18Z<p>Twnaing: initial stub page</p>
<hr />
<div>IPMI - Intelligent Platform Management Interface is a set of computer interface specifications for an autonomous computer subsystem that provides management and monitoring capabilities independently of the host system's CPU, firmware (BIOS or UEFI) and operating system.<br />
<br />
ArchLinux has the following IPMI related packages<br />
<br />
* [https://aur.archlinux.org/packages/freeipmi/ FreeIPMI]<br />
* [https://www.archlinux.org/packages/community/x86_64/openipmi/ OpenIPMI]<br />
* [https://aur.archlinux.org/packages/ipmiutil/ Ipmiutil]<br />
* [https://www.archlinux.org/packages/community/x86_64/ipmitool/ IPMITool]</div>Twnainghttps://wiki.archlinux.org/index.php?title=Netdata&diff=467269Netdata2017-01-31T11:32:41Z<p>Twnaing: Created page with "<blockquote>Get control of your servers. Simple. Effective. Awesome.</blockquote> [https://github.com/firehol/netdata/ netdata] is a system for distributed real-time performa..."</p>
<hr />
<div><blockquote>Get control of your servers. Simple. Effective. Awesome.</blockquote><br />
<br />
[https://github.com/firehol/netdata/ netdata] is a system for distributed real-time performance and health monitoring. It provides unparalleled insights, in real-time, of everything happening on the system it runs (including applications such as web and database servers), using modern interactive web dashboards.<br />
<br />
netdata is fast and efficient, designed to permanently run on all systems (physical & virtual servers, containers, IoT devices), without disrupting their core function.<br />
<br />
== Installation ==<br />
<br />
netdata can be installed using [https://www.archlinux.org/packages/?sort=&q=netdata netdata] community package<br />
<br />
sudo pacman -S netdata<br />
<br />
== Enable at startup ==<br />
<br />
sudo systemctl enable netdata<br />
<br />
== Control the service ==<br />
<br />
sudo systemctl start netdata<br />
<br />
== Configuring ==<br />
<br />
Configuration file is located at <code>/etc/netdata/netdata.conf</code><br />
<br />
plugins folders is at <code>/usr/lib/netdata</code><br />
<br />
=== Netdata behind web server ===<br />
<br />
netdata can be run behind another server and you can configure it accordingly. The [https://github.com/firehol/netdata/wiki/Running-behind-nginx wiki] page has example for Apache, Nginx, lighttpd and caddy.<br />
<br />
=== Using built in webserver ===<br />
<br />
By default netdata is accessible at <code>http://localhost:19999/</code> or <code>http://ip:19999/</code><br />
<br />
=== Optimization ===<br />
<br />
netdata can be optimized for <br />
<br />
# low resource (or)<br />
# high performance<br />
<br />
== Related ==<br />
<br />
netdata is created by the group who also created<br />
<br />
* FireHOL and FireQOS</div>Twnainghttps://wiki.archlinux.org/index.php?title=FireHOL&diff=457311FireHOL2016-11-20T18:46:29Z<p>Twnaing: initial page</p>
<hr />
<div>[http://firehol.org FireHOL] is a language (and a program to run it) which builds secure, stateful firewalls from easy to understand, human-readable configurations. The configurations stay readable even for very complex setups.<br />
<br />
== Installation ==<br />
<br />
Install [http://aur.archlinux.org/packages/firehol/ Firehol] or [http://aur.archlinux.org/pkgbase/firehol-git/ Firehol-git] from AUR.<br />
<br />
== Configuration ==<br />
<br />
Configuration file is at <code>/etc/firehol/firehol.conf</code><br />
<br />
Copy example config from [http://firehol.org/#firehol Firehol example]<br />
<br />
The configuration file is bash file and has 3 parts<br />
<br />
* helper<br />
* interface<br />
* router<br />
<br />
== Try, Run and Enable ==<br />
<br />
You can try the config file is correct or not by<br />
<br />
sudo firehol try<br />
<br />
or<br />
<br />
sudo firehol nofast try<br />
<br />
If the config is working, run the Firehol by<br />
<br />
systemctl start firehol<br />
<br />
Enable Firehol to run at boot time by<br />
<br />
systemctl enable firehol<br />
<br />
== Related ==<br />
<br />
You may configure Fireqos for QoS and NetData for monitoring</div>Twnaing