title: idmap_autorid(8)

summary: Samba\*(Aqs idmap_autorid Backend for Winbind

text:
# idmap_autorid(8)

## NAME
idmap_autorid - Samba's idmap_autorid Backend for Winbind

## DESCRIPTION
The idmap_autorid backend provides a way to use an algorithmic mapping scheme to map UIDs/GIDs and SIDs that is more deterministic than idmap_tdb and easier to configure than idmap_rid.

The module works similar to idmap_rid, but it automatically configures the range to be used for each domain, so there is no need to specify a specific range for each domain in the forest, the only configuration that is needed is the range of uid/gids that shall be used for user/group mappings and an optional size of the ranges to be used.

The mappings of which domain is mapped to which range is stored in autorid.tdb, thus you should backup this database regularly.

Due to the algorithm being used, it is the module that is most easy to use as it only requires a minimal configuration.

## IDMAP OPTIONS
range = low - high

Defines the available matching uid and gid range for which the backend is authoritative. Note that the range acts as a filter. If algorithmically determined UID or GID fall outside the range, they are ignored and the corresponding map is discarded. It is intended as a way to avoid accidental UID/GID overlaps between local and remotely defined IDs. Note that the range should be a multiple of the rangesize and needs to be at least twice as large in order to have sufficient id range space for the mandatory BUILTIN domain. With a default rangesize of 100000 the range needs to span at least 200000. This would be: range = 100000 - 299999.

rangesize = numberofidsperrange

Defines the number of uids/gids available per domain range. The minimum needed value is 2000. SIDs with RIDs larger than this value will be mapped into extension ranges depending upon number of available ranges. If the autorid backend runs out of available ranges, mapping requests for new domains (or new extension ranges for domains already known) are ignored and the corresponding map is discarded. Example: with rangesize set to 10000, users/groups with a RID up to 10000 will be put into the first range for the domain. When attempting to map the an object with a RID of 25000, an extension range will be allocated that will then be used to map all RIDs from 20000-29999.

One range will be used for local users and groups and for non-domain well-known SIDs like Everyone (S-1-1-0) or Creator Owner (S-1-3-0). A chosen list of well-known SIDs will be preallocated on first start to create deterministic mappings for those.

Thus the number of local users and groups that can be created is limited by this option as well. If you plan to create a large amount of local users or groups, you will need set this parameter accordingly.

The default value is 100000.

read only = [ yes | no ]

Turn the module into read-only mode. No new ranges will be allocated nor will new mappings be created in the idmap pool. Defaults to no.

ignore builtin = [ yes | no ]

Ignore any mapping requests for the BUILTIN domain. Defaults to no.

## THE MAPPING FORMULAS
The Unix ID for a RID is calculated this way:

```
			ID =  REDUCED RID + IDMAP RANGE LOW VALUE + RANGE NUMBER * RANGE SIZE

```

where REDUCED RID = RID % RANGE_SIZE and a DOMAIN RANGE INDEX = RID / RANGE_SIZE is used together with the domain sid to determine the RANGE NUMBER (stored in the database).

Correspondingly, the formula for calculating the RID for a given Unix ID is this:

```
			RID = (ID - LOW ID) % RANGE SIZE + DOMAIN RANGE INDEX * RANGE SIZE

```

Where the DOMAIN RANGE INDEX is retrieved from the database along with the domain sid by the RANGE NUMBER = (ID - LOW ID) / RANGE SIZE .

## EXAMPLES
This example shows you the minimal configuration that will work for the principal domain and 19 trusted domains / range extensions.

```
	[global]
	security = ads
	workgroup = CUSTOMER
	realm = CUSTOMER.COM
	idmap config * : backend = autorid
	idmap config * : range = 1000000-1999999

```

This example shows how to configure idmap_autorid as default for all domains with a potentially large amount of users plus a specific configuration for a trusted domain that uses the SFU mapping scheme. Please note that idmap ranges and sfu ranges are not allowed to overlap.

```
	[global]
	security = ads
	workgroup = CUSTOMER
	realm = CUSTOMER.COM
	idmap config * : backend = autorid
	idmap config * : range = 1000000-19999999
	idmap config * : rangesize = 1000000
	idmap config TRUSTED : backend  = ad
	idmap config TRUSTED : range    = 50000 - 99999
	idmap config TRUSTED : schema_mode = sfu

```

## AUTHOR
The original Samba software and related utilities were created by Andrew Tridgell. Samba is now developed by the Samba Team as an Open Source project similar to the way the Linux kernel is developed.


package: samba-winbind-common

title: idmap_hash(8)

summary: DO NOT USE THIS BACKEND

text:
# idmap_hash(8)

## NAME
idmap_hash - DO NOT USE THIS BACKEND

## DESCRIPTION
DO NOT USE THIS PLUGIN The idmap_hash plugin implements a hashing algorithm used to map SIDs for domain users and groups to 31-bit uids and gids, respectively. This plugin also implements the nss_info API and can be used to support a local name mapping files if enabled via the "winbind normalize names" and "winbind nss info" parameters in /etc/samba/smb.conf. The module divides the range into subranges for each domain that is being handled by the idmap config. The module needs the complete UID and GID range to be able to map all SIDs. The lowest value for the range should be the smallest ID available in the system. This is normally 1000. The highest ID should be set to 2147483647. A smaller range will lead to issues because of the hashing algorithm used. The overall range to map all SIDs is 0 - 2147483647. Any range smaller than 0 - 2147483647 will filter some SIDs. As we can normally only start with 1000, we are not able to map 1000 SIDs. This already can lead to issues. The smaller the range the less SIDs can be mapped. We do not recommend to use this plugin. It will be removed in a future release of Samba.

## IDMAP OPTIONS
name_map

Specifies the absolute path to the name mapping file used by the nss_info API. Entries in the file are of the form "unix name = qualified domain name". Mapping of both user and group names is supported.

## EXAMPLES
The following example utilizes the idmap_hash plugin for the idmap and nss_info information.

```
	[global]
	idmap config * : backend = hash
	idmap config * : range = 1000-2147483647
	winbind nss info = hash
	winbind normalize names = yes
	idmap_hash:name_map = /etc/samba/name_map.cfg

```

## AUTHOR
The original Samba software and related utilities were created by Andrew Tridgell. Samba is now developed by the Samba Team as an Open Source project similar to the way the Linux kernel is developed.

branch: sisyphus


title: idmap_ldap(8)

summary: Samba\*(Aqs idmap_ldap Backend for Winbind

text:
# idmap_ldap(8)

## NAME
idmap_ldap - Samba's idmap_ldap Backend for Winbind

## DESCRIPTION
The idmap_ldap plugin provides a means for Winbind to store and retrieve SID/uid/gid mapping tables in an LDAP directory service.

In contrast to read only backends like idmap_rid, it is an allocating backend: This means that it needs to allocate new user and group IDs in order to create new mappings.

## IDMAP OPTIONS
ldap_base_dn = DN

Defines the directory base suffix to use for SID/uid/gid mapping entries. If not defined, idmap_ldap will default to using the "ldap idmap suffix" option from /etc/samba/smb.conf.

ldap_user_dn = DN

Defines the user DN to be used for authentication. The secret for authenticating this user should be stored with net idmap secret (see net(8)). If absent, the ldap credentials from the ldap passdb configuration are used, and if these are also absent, an anonymous bind will be performed as last fallback.

ldap_url = ldap://server/

Specifies the LDAP server to use for SID/uid/gid map entries. If not defined, idmap_ldap will assume that ldap://localhost/ should be used.

range = low - high

Defines the available matching uid and gid range for which the backend is authoritative.

## EXAMPLES
The following example shows how an ldap directory is used as the default idmap backend. It also configures the idmap range and base directory suffix. The secret for the ldap_user_dn has to be set with "net idmap secret '*' password".

```
	[global]
	idmap config * : backend      = ldap
	idmap config * : range        = 1000000-1999999
	idmap config * : ldap_url     = ldap://localhost/
	idmap config * : ldap_base_dn = ou=idmap,dc=example,dc=com
	idmap config * : ldap_user_dn = cn=idmap_admin,dc=example,dc=com

```

This example shows how ldap can be used as a readonly backend while tdb is the default backend used to store the mappings. It adds an explicit configuration for some domain DOM1, that uses the ldap idmap backend. Note that a range disjoint from the default range is used.

```
	[global]
	# "backend = tdb" is redundant here since it is the default
	idmap config * : backend = tdb
	idmap config * : range = 1000000-1999999
	idmap config DOM1 : backend = ldap
	idmap config DOM1 : range = 2000000-2999999
	idmap config DOM1 : read only = yes
	idmap config DOM1 : ldap_url = ldap://server/
	idmap config DOM1 : ldap_base_dn = ou=idmap,dc=dom1,dc=example,dc=com
	idmap config DOM1 : ldap_user_dn = cn=idmap_admin,dc=dom1,dc=example,dc=com

```

## NOTE
In order to use authentication against ldap servers you may need to provide a DN and a password. To avoid exposing the password in plain text in the configuration file we store it into a security store. The "net idmap " command is used to store a secret for the DN specified in a specific idmap domain.

## AUTHOR
The original Samba software and related utilities were created by Andrew Tridgell. Samba is now developed by the Samba Team as an Open Source project similar to the way the Linux kernel is developed.


title: idmap_nss(8)

summary: Samba\*(Aqs idmap_nss Backend for Winbind

text:
# idmap_nss(8)

## NAME
idmap_nss - Samba's idmap_nss Backend for Winbind

## DESCRIPTION
The idmap_nss plugin provides a means to map Unix users and groups to Windows accounts. This provides a simple means of ensuring that the SID for a Unix user named jsmith is reported as the one assigned to DOMAIN\jsmith which is necessary for reporting ACLs on files and printers stored on a Samba member server.

## IDMAP OPTIONS
range = low - high

Defines the available matching UID and GID range for which the backend is authoritative. Note that the range acts as a filter. Returned UIDs or GIDs by NSS modules that fall outside the range are ignored and the corresponding maps discarded. It is intended as a way to avoid accidental UID/GID overlaps between local and remotely defined IDs.

use_upn = <yes | no>

Some NSS modules can return and handle UPNs and/or down-level logon names (e.g., DOMAIN\user or user@REALM). If this parameter is enabled the returned names from NSS will be parsed and the resulting namespace will be used as the authoritative namespace instead of the IDMAP domain name. Also, down-level logon names will be sent to NSS instead of the plain username to give NSS modules a hint about the user's correct domain.

Default: no

## EXAMPLES
This example shows how to use idmap_nss to obtain the local account ID's for its own domain (SAMBA) from NSS, whilst allocating new mappings for the default domain (*) and any trusted domains.

```
	[global]
	idmap config * : backend = tdb
	idmap config * : range = 1000000-1999999
	idmap config SAMBA : backend  = nss
	idmap config SAMBA : range = 1000-999999

```

## AUTHOR
The original Samba software and related utilities were created by Andrew Tridgell. Samba is now developed by the Samba Team as an Open Source project similar to the way the Linux kernel is developed.


title: idmap_rfc2307(8)

summary: Samba\*(Aqs idmap_rfc2307 Backend for Winbind

text:
# idmap_rfc2307(8)

## NAME
idmap_rfc2307 - Samba's idmap_rfc2307 Backend for Winbind

## DESCRIPTION
The idmap_rfc2307 plugin provides a way for winbind to read id mappings from records in an LDAP server as defined in RFC 2307. The LDAP server can be stand-alone or the LDAP server provided by the AD server. An AD server is always required to provide the mapping between name and SID, and the LDAP server is queried for the mapping between name and uid/gid. This module implements only the "idmap" API, and is READONLY.

Mappings must be provided in advance by the administrator by creating the user accounts in the Active Directory server and the posixAccount and posixGroup objects in the LDAP server. The names in the Active Directory server and in the LDAP server have to be the same.

This id mapping approach allows the reuse of existing LDAP authentication servers that store records in the RFC 2307 format.

When connecting to the LDAP server provided by an AD server, the parameter ldap ssl ads determines whether SSL should be used. When using a stand-alone LDAP server, ldap ssl applies.

## IDMAP OPTIONS
range = low - high

Defines the available matching UID and GID range for which the backend is authoritative. Note that the range acts as a filter. If specified any UID or GID stored in AD that fall outside the range is ignored and the corresponding map is discarded. It is intended as a way to avoid accidental UID/GID overlaps between local and remotely defined IDs.

ldap_server = <ad | stand-alone >

Defines the type of LDAP server to use. This can either be the LDAP server provided by the Active Directory server (ad) or a stand-alone LDAP server.

bind_path_user

Specifies the search base where user objects can be found in the LDAP server.

bind_path_group

Specifies the search base where group objects can be found in the LDAP server.

user_cn = <yes | no>

Query cn attribute instead of uid attribute for the user name in LDAP. This option is not required, the default is no.

realm

Append @realm to cn for groups (and users if user_cn is set) in LDAP queries. This option is not required, the default is not to append the realm.

ldap_domain

When using the LDAP server in the Active Directory server, this allows one to specify the domain where to access the Active Directory server. This allows using trust relationships while keeping all RFC 2307 records in one place. This parameter is optional, the default is to access the AD server in the current domain to query LDAP records.

ldap_url

When using a stand-alone LDAP server, this parameter specifies the ldap URL for accessing the LDAP server.

ldap_user_dn

Defines the user DN to be used for authentication. The secret for authenticating this user should be stored with net idmap secret (see net(8)). If absent, an anonymous bind will be performed.

## EXAMPLES
The following example shows how to retrieve id mappings from a stand-alone LDAP server. This example also shows how to leave a small non conflicting range for local id allocation that may be used in internal backends like BUILTIN.

```
	[global]
	idmap config * : backend = tdb
	idmap config * : range = 1000000-1999999
	idmap config DOMAIN : backend = rfc2307
	idmap config DOMAIN : range = 2000000-2999999
	idmap config DOMAIN : ldap_server = stand-alone
	idmap config DOMAIN : ldap_url = ldap://ldap1.example.com
	idmap config DOMAIN : ldap_user_dn = cn=ldapmanager,dc=example,dc=com
	idmap config DOMAIN : bind_path_user = ou=People,dc=example,dc=com
	idmap config DOMAIN : bind_path_group = ou=Group,dc=example,dc=com

```

## AUTHOR
The original Samba software and related utilities were created by Andrew Tridgell. Samba is now developed by the Samba Team as an Open Source project similar to the way the Linux kernel is developed.


title: idmap_rid(8)

summary: Samba\*(Aqs idmap_rid Backend for Winbind

text:
# idmap_rid(8)

## NAME
idmap_rid - Samba's idmap_rid Backend for Winbind

## DESCRIPTION
The idmap_rid backend provides a way to use an algorithmic mapping scheme to map UIDs/GIDs and SIDs. No database is required in this case as the mapping is deterministic.

Currently, there should to be an explicit idmap configuration for each domain that should use the idmap_rid backend, using disjoint ranges.

NOTE: The idmap_rid backend can NOT be used as the default backend. One usually needs to define a writeable default idmap range, using a backend like tdb or ldap that can create unix ids, in order to be able to map the BUILTIN sids and other domains, and also in order to be able to create group mappings. See the example below.

## IDMAP OPTIONS
range = low - high

Defines the available matching uid and gid range for which the backend is authoritative. Note that the range acts as a filter. If algorithmically determined UID or GID fall outside the range, they are ignored and the corresponding map is discarded. It is intended as a way to avoid accidental UID/GID overlaps between local and remotely defined IDs.

base_rid = INTEGER

Defines the base integer used to build SIDs out of a UID or a GID, and to rebase the UID or GID to be obtained from a SID. This means SIDs with a RID less than the base rid are filtered. The default is not to restrict the allowed rids at all, i.e. a base_rid value of 0. Use of this parameter is deprecated.

## THE MAPPING FORMULAS
The Unix ID for a RID is calculated this way:

```
			ID = RID - BASE_RID + LOW_RANGE_ID.

```

Correspondingly, the formula for calculating the RID for a given Unix ID is this:

```
			RID = ID + BASE_RID - LOW_RANGE_ID.

```

## EXAMPLES
This example shows how to configure two domains with idmap_rid, the principal domain and a trusted domain, leaving the default id mapping scheme at tdb. The example also demonstrates the use of the base_rid parameter for the trusted domain.

```
	[global]
	security = domain
	workgroup = MAIN
	idmap config * : backend        = tdb
	idmap config * : range          = 1000000-1999999
	idmap config MAIN : backend     = rid
	idmap config MAIN : range       = 10000 - 49999
	idmap config TRUSTED : backend  = rid
	idmap config TRUSTED : range    = 50000 - 99999
	idmap config TRUSTED : base_rid = 500000

```

## AUTHOR
The original Samba software and related utilities were created by Andrew Tridgell. Samba is now developed by the Samba Team as an Open Source project similar to the way the Linux kernel is developed.


title: idmap_script(8)

summary: Samba\*(Aqs idmap_script Backend for Winbind

text:
# idmap_script(8)

## NAME
idmap_script - Samba's idmap_script Backend for Winbind

## DESCRIPTION
The idmap_script plugin is a substitute for the idmap_tdb2 backend used by winbindd for storing SID/uid/gid mapping tables in clustered environments with Samba and CTDB. It is a read only backend that uses a script to perform mapping.

It was developed out of the idmap_tdb2 back end and does not store SID/uid/gid mappings in a TDB, since the winbind_cache tdb will store the mappings once they are provided.

## IDMAP OPTIONS
range = low - high

Defines the available matching uid and gid range for which the backend is authoritative.

script

This option can be used to configure an external program for performing id mappings.

## IDMAP SCRIPT
The script idmap backend supports an external program for performing id mappings through the /etc/samba/smb.conf option idmap config * : script or its deprecated legacy form idmap : script.

The script should accept the following command line options.

```
	SIDTOID S-1-xxxx
	IDTOSID UID xxxx
	IDTOSID GID xxxx
	IDTOSID XID xxxx

```

And it should return one of the following responses as a single line of text.

```
	UID:yyyy
	GID:yyyy
	XID:yyyy
	SID:ssss
	ERR:yyyy

```

XID indicates that the ID returned should be both a UID and a GID. That is, it requests an ID_TYPE_BOTH, but it is ultimately up to the script whether or not it can honor that request. It can choose to return a UID or a GID mapping only.

## EXAMPLES
This example shows how script is used as the default idmap backend using an external program via the script parameter:

```
	[global]
	idmap config * : backend = script
	idmap config * : range = 1000000-2000000
	idmap config * : script = /usr/local/samba/bin/idmap_script.sh

```

This shows a simple script to partially perform the task:

```
	#!/bin/sh
	#
	# Uncomment this if you want some logging
	#echo $@ >> /tmp/idmap.sh.log
	if [ "$1" == "SIDTOID" ]
	then
		# Note. The number returned has to be within the range defined
		#echo "Sending UID:1000005" >> /tmp/idmap.sh.log
		echo "UID:1000005"
		exit 0
	else
		#echo "Sending ERR: No idea what to do" >> /tmp/idmap.sh.log
		echo "ERR: No idea what to do"
		exit 1
	fi

```

Clearly, this script is not enough, as it should probably use wbinfo to determine if an incoming SID is a user or group SID and then look up the mapping in a table or use some other mechanism for mapping SIDs to UIDs and etc.

Please be aware that the script is called with the _NO_WINBINDD environment variable set to 1. This prevents recursive calls into winbind from the script both via explicit calls to wbinfo and via implicit calls via nss_winbind. For example a call to ls -l could trigger such an infinite recursion.

It is safe to call wbinfo -n and wbinfo -s from within an idmap script. To do so, the script must unset the _NO_WINBINDD environment variable right before the call to wbinfo and set it to 1 again right after wbinfo has returned to protect against the recursion.

## AUTHOR
The original Samba software and related utilities were created by Andrew Tridgell. Samba is now developed by the Samba Team as an Open Source project similar to the way the Linux kernel is developed.


title: idmap_tdb(8)

summary: Samba\*(Aqs idmap_tdb Backend for Winbind

text:
# idmap_tdb(8)

## NAME
idmap_tdb - Samba's idmap_tdb Backend for Winbind

## DESCRIPTION
The idmap_tdb plugin is the default backend used by winbindd for storing SID/uid/gid mapping tables.

In contrast to read only backends like idmap_rid, it is an allocating backend: This means that it needs to allocate new user and group IDs in order to create new mappings.

## IDMAP OPTIONS
range = low - high

Defines the available matching uid and gid range for which the backend is authoritative.

## EXAMPLES
This example shows how tdb is used as the default idmap backend. This configured range is used for uid and gid allocation.

```
	[global]
	# "backend = tdb" is redundant here since it is the default
	idmap config * : backend = tdb
	idmap config * : range = 1000000-2000000

```

## AUTHOR
The original Samba software and related utilities were created by Andrew Tridgell. Samba is now developed by the Samba Team as an Open Source project similar to the way the Linux kernel is developed.


title: idmap_tdb2(8)

summary: Samba\*(Aqs idmap_tdb2 Backend for Winbind

text:
# idmap_tdb2(8)

## NAME
idmap_tdb2 - Samba's idmap_tdb2 Backend for Winbind

## DESCRIPTION
The idmap_tdb2 plugin is a substitute for the default idmap_tdb backend used by winbindd for storing SID/uid/gid mapping tables in clustered environments with Samba and CTDB.

In contrast to read only backends like idmap_rid, it is an allocating backend: This means that it needs to allocate new user and group IDs in order to create new mappings.

## IDMAP OPTIONS
range = low - high

Defines the available matching uid and gid range for which the backend is authoritative.

script

This option can be used to configure an external program for performing id mappings instead of using the tdb counter. The mappings are then stored int tdb2 idmap database. For details see the section on IDMAP SCRIPT below.

## IDMAP SCRIPT
The tdb2 idmap backend supports an external program for performing id mappings through the smb.conf option idmap config * : script or its deprecated legacy form idmap : script.

The mappings obtained by the script are then stored in the idmap tdb2 database instead of mappings created by the incrementing id counters. It is therefore important that the script covers the complete range of SIDs that can be passed in for SID to Unix ID mapping, since otherwise SIDs unmapped by the script might get mapped to IDs that had previously been mapped by the script.

The script should accept the following command line options.

```
	SIDTOID S-1-xxxx
	IDTOSID UID xxxx
	IDTOSID GID xxxx

```

And it should return one of the following responses as a single line of text.

```
	UID:yyyy
	GID:yyyy
	SID:yyyy
	ERR:yyyy

```

## EXAMPLES
This example shows how tdb2 is used as the default idmap backend.

```
	[global]
	idmap config * : backend = tdb2
	idmap config * : range = 1000000-2000000

```

This example shows how tdb2 is used as the default idmap backend using an external program via the script parameter:

```
	[global]
	idmap config * : backend = tdb2
	idmap config * : range = 1000000-2000000
	idmap config * : script = /usr/local/samba/bin/idmap_script.sh

```

## AUTHOR
The original Samba software and related utilities were created by Andrew Tridgell. Samba is now developed by the Samba Team as an Open Source project similar to the way the Linux kernel is developed.


winbindd

title: winbindd(8)

text:
# winbindd(8)

## NAME
winbindd - Name Service Switch daemon for resolving names from NT servers

## SYNOPSIS
winbindd [-D|--daemon] [-i|--interactive] [-F|--foreground] [--no-process-group] [-n|--no-caching] [-d <debug level>] [--debug-stdout] [--configfile=<configuration file>] [--option=<name>=<value>] [-l|--log-basename <log directory>] [--leak-report] [--leak-report-full] [-V|--version]

## DESCRIPTION
This program is part of the samba(7) suite.

winbindd is a daemon that provides a number of services to the Name Service Switch capability found in most modern C libraries, to arbitrary applications via PAM and ntlm_auth and to Samba itself.

Even if winbind is not used for nsswitch, it still provides a service to smbd, ntlm_auth and the pam_winbind.so PAM module, by managing connections to domain controllers. In this configuration the idmap config * : range parameter is not required. (This is known as `netlogon proxy only mode'.)

The Name Service Switch allows user and system information to be obtained from different databases services such as NIS or DNS. The exact behaviour can be configured through the /etc/nsswitch.conf file. Users and groups are allocated as they are resolved to a range of user and group ids specified by the administrator of the Samba system.

The service provided by winbindd is called `winbind' and can be used to resolve user and group information from a Windows NT server. The service can also provide authentication services via an associated PAM module.

The pam_winbind module supports the auth, account and password module-types. It should be noted that the account module simply performs a getpwnam() to verify that the system can obtain a uid for the user, as the domain controller has already performed access control. If the libnss_winbind library has been correctly installed, or an alternate source of names configured, this should always succeed.

The following nsswitch databases are implemented by the winbindd service:

hosts

This feature is only available on IRIX. User information traditionally stored in the hosts(5) file and used by gethostbyname(3) functions. Names are resolved through the WINS server or by broadcast.

passwd

User information traditionally stored in the passwd(5) file and used by getpwent(3) functions.

group

Group information traditionally stored in the group(5) file and used by getgrent(3) functions.

For example, the following simple configuration in the /etc/nsswitch.conf file can be used to initially resolve user and group information from /etc/passwd and /etc/group and then from the Windows NT server.

```
passwd:         files winbind
group:          files winbind
## only available on IRIX: use winbind to resolve hosts:
# hosts:        files dns winbind
## All other NSS enabled systems should use libnss_wins.so like this:
hosts:          files dns wins
```

The following simple configuration in the /etc/nsswitch.conf file can be used to initially resolve hostnames from /etc/hosts and then from the WINS server.

```
hosts:		files wins
```

## OPTIONS
-D|--daemon

If specified, this parameter causes the server to operate as a daemon. That is, it detaches itself and runs in the background on the appropriate port. This switch is assumed if winbindd is executed on the command line of a shell.

-i|--interactive

Tells winbindd to not become a daemon and detach from the current terminal. This option is used by developers when interactive debugging of winbindd is required. winbindd also logs to standard output, as if the -S parameter had been given.

-F|--foreground

If specified, this parameter causes the main winbindd process to not daemonize, i.e. double-fork and disassociate with the terminal. Child processes are still created as normal to service each connection request, but the main process does not exit. This operation mode is suitable for running winbindd under process supervisors such as supervise and svscan from Daniel J. Bernstein's daemontools package, or the AIX process monitor.

--no-process-group

Do not create a new process group for winbindd.

-n|--no-caching

Disable some caching. This means winbindd will often have to wait for a response from the domain controller before it can respond to a client and this thus makes things slower. The results will however be more accurate, since results from the cache might not be up-to-date. This might also temporarily hang winbindd if the DC doesn't respond. This does not disable the samlogon cache, which is required for group membership tracking in trusted environments.

-d|--debuglevel=level

level is an integer from 0 to 10. The default value if this parameter is not specified is 0. The higher this value, the more detail will be logged to the log files about the activities of the server. At level 0, only critical errors and serious warnings will be logged. Level 1 is a reasonable level for day-to-day running - it generates a small amount of information about operations carried out.

Levels above 1 will generate considerable amounts of log data, and should only be used when investigating a problem. Levels above 3 are designed for use only by developers and generate HUGE amounts of log data, most of which is extremely cryptic.

Note that specifying this parameter here will override the log level parameter in the /etc/samba/smb.conf file.

--debug-stdout

This will redirect debug output to STDOUT. By default server daemons are logging to a log file.

--configfile=CONFIGFILE

The file specified contains the configuration details required by the server. The information in this file includes server-specific information such as what printcap file to use, as well as descriptions of all the services that the server is to provide. See /etc/samba/smb.conf for more information. The default configuration file name is determined at compile time.

--option=<name>=<value>

Set the smb.conf(5) option "<name>" to value "<value>" from the command line. This overrides compiled-in defaults and options read from the configuration file. If a name or a value includes a space, wrap whole --option=name=value into quotes.

-l|--log-basename=logdirectory

Base directory name for log/debug files. The parent process uses filename log.winbindd, the child process uses filename log.wb-<name>. The log file is never removed by winbindd.

--leak-report

Enable talloc leak reporting on exit.

--leak-report-full

Enable full talloc leak reporting on exit.

-V|--version

Prints the program version number.

-?|--help

Print a summary of command line options.

--usage

Display brief usage message.

## NAME AND ID RESOLUTION
Users and groups on a Windows NT server are assigned a security id (SID) which is globally unique when the user or group is created. To convert the Windows NT user or group into a unix user or group, a mapping between SIDs and unix user and group ids is required. This is one of the jobs that winbindd performs.

As winbindd users and groups are resolved from a server, user and group ids are allocated from a specified range. This is done on a first come, first served basis, although all existing users and groups will be mapped as soon as a client performs a user or group enumeration command. The allocated unix ids are stored in a database and will be remembered.

WARNING: The SID to unix id database is the only location where the user and group mappings are stored by winbindd. If this store is deleted or corrupted, there is no way for winbindd to determine which user and group ids correspond to Windows NT user and group rids.

## CONFIGURATION
Configuration of the winbindd daemon is done through configuration parameters in the smb.conf(5) file. All parameters should be specified in the [global] section of smb.conf.

•winbind separator

•idmap config * : range

•idmap config * : backend

•winbind cache time

•winbind enum users

•winbind enum groups

•template homedir

•template shell

•winbind use default domain

•winbind: rpc only Setting this parameter forces winbindd to use RPC instead of LDAP to retrieve information from Domain Controllers.

## EXAMPLE SETUP
To setup winbindd for user and group lookups plus authentication from a domain controller use something like the following setup. This was tested on an early Red Hat Linux box.

In /etc/nsswitch.conf put the following:

```
passwd: files winbind
group:  files winbind
```

In /etc/pam.d/* replace the auth lines with something like this:

```
auth  required    /lib/security/pam_securetty.so
auth  required	  /lib/security/pam_nologin.so
auth  sufficient  /lib/security/pam_winbind.so
auth  required    /lib/security/pam_unix.so \

                  use_first_pass shadow nullok
```

Note

The PAM module pam_unix has recently replaced the module pam_pwdb. Some Linux systems use the module pam_unix2 in place of pam_unix.

Note in particular the use of the sufficient keyword and the use_first_pass keyword.

Now replace the account lines with this:

account required /lib/security/pam_winbind.so

The next step is to join the domain. To do that use the net program like this:

net join -S PDC -U Administrator

The username after the -U can be any Domain user that has administrator privileges on the machine. Substitute the name or IP of your PDC for "PDC".

Next copy libnss_winbind.so to /lib and pam_winbind.so to /lib/security. A symbolic link needs to be made from /lib/libnss_winbind.so to /lib/libnss_winbind.so.2. If you are using an older version of glibc then the target of the link should be /lib/libnss_winbind.so.1.

Finally, setup a smb.conf(5) containing directives like the following:

```
[global]
	winbind separator = +

        winbind cache time = 10

        template shell = /bin/bash

        template homedir = /home/%D/%U

        idmap config * : range = 10000-20000

        workgroup = DOMAIN

        security = domain

        password server = *
```

Now start winbindd and you should find that your user and group database is expanded to include your NT users and groups, and that you can login to your unix box as a domain user, using the DOMAIN+user syntax for the username. You may wish to use the commands getent passwd and getent group to confirm the correct operation of winbindd.

## NOTES
The following notes are useful when configuring and running winbindd:

PAM is really easy to misconfigure. Make sure you know what you are doing when modifying PAM configuration files. It is possible to set up PAM such that you can no longer log into your system.

If more than one UNIX machine is running winbindd, then in general the user and groups ids allocated by winbindd will not be the same. The user and group ids will only be valid for the local machine, unless a shared idmap config * : backend is configured.

If the Windows NT SID to UNIX user and group id mapping file is damaged or destroyed then the mappings will be lost.

## SIGNALS
The following signals can be used to manipulate the winbindd daemon.

SIGHUP

Reload the smb.conf(5) file and apply any parameter changes to the running version of winbindd. This signal also clears any cached user and group information. The list of other domains trusted by winbindd is also reloaded. Instead of sending a SIGHUP signal, a request to reload configuration file may be sent using smbcontrol(1) program.

SIGUSR2

The SIGUSR2 signal will cause winbindd to write status information to the winbind log file. Log files are stored in the filename specified by the log file parameter.

## FILES
/etc/nsswitch.conf(5)

Name service switch configuration file.

/run/samba/winbindd/pipe

The UNIX pipe over which clients communicate with the winbindd program. For security reasons, the winbind client will only attempt to connect to the winbindd daemon if both the /run/samba/winbindd directory and /run/samba/winbindd/pipe file are owned by root. winbindd socket directory overrides this default.

$STATEDIR/winbindd_privileged/pipe

The UNIX pipe over which 'privileged' clients communicate with the winbindd program. For security reasons, access to some winbindd functions - like those needed by the ntlm_auth utility - is restricted. By default, only users in the 'root' group will get this access, however the administrator may change the group permissions on $STATEDIR/winbindd_privileged to allow programs like 'squid' to use ntlm_auth. Note that the winbind client will only attempt to connect to the winbindd daemon if both the $STATEDIR/winbindd_privileged directory and $STATEDIR/winbindd_privileged/pipe file are owned by root. state dir controls what $STATEDIR refers to.

/lib/libnss_winbind.so.X

Implementation of name service switch library.

$STATEDIR/winbindd_idmap.tdb

Storage for the Windows NT rid to UNIX user/group id mapping. The directory is specified when Samba is initially compiled using the --with-statedir option or state dir. The default directory in this installation is /var/lib/samba.

$LOCKDIR/winbindd_cache.tdb

Storage for cached user and group information.

## VERSION
This man page is part of version 4.22.10-alt1 of the Samba suite.

## SEE ALSO
nsswitch.conf(5), samba(7), wbinfo(1), ntlm_auth(8), smb.conf(5), pam_winbind(8)

## AUTHOR
The original Samba software and related utilities were created by Andrew Tridgell. Samba is now developed by the Samba Team as an Open Source project similar to the way the Linux kernel is developed.

wbinfo and winbindd were written by Tim Potter.

The conversion to DocBook for Samba 2.2 was done by Gerald Carter. The conversion to DocBook XML 4.2 for Samba 3.0 was done by Alexander Bokovoy.


title: winbind_krb5_localauth(8)

text:
# winbind_krb5_localauth(8)

## NAME
winbind_krb5_localauth - A plugin for MIT Kerberos for mapping user accounts.

## DESCRIPTION
This plugin is part of the samba(7) suite.

winbind_krb5_localauth is a plugin that permits the MIT Kerberos libraries that Kerberos principals can be validated against local user accounts.

## PREREQUISITES
MIT Kerberos (at least version 1.12) is required.

The plugin queries the winbindd(8) daemon which needs to be configured and started separately.

The following sections needs to be added to the krb5.conf file.

```
[plugins]
	localauth = {
		module = winbind:/usr/lib64/samba/krb5/winbind_krb5_localauth.so
		enable_only = winbind
	}

```

## VERSION
This man page is part of version 4.22.10-alt1 of the Samba suite.

## AUTHOR
The original Samba software and related utilities were created by Andrew Tridgell. Samba is now developed by the Samba Team as an Open Source project similar to the way the Linux kernel is developed.

The winbind_krb5_localauth manpage was written by Andreas Schneider.


title: winbind_krb5_locator(8)

text:
# winbind_krb5_locator(8)

## NAME
winbind_krb5_locator - A plugin for MIT and Heimdal Kerberos for detecting KDCs using Windows semantics.

## DESCRIPTION
This plugin is part of the samba(7) suite.

winbind_krb5_locator is a plugin that permits MIT and Heimdal Kerberos libraries to detect Kerberos Servers (for the KDC and kpasswd service) using the same semantics that other tools of the Samba suite use. This include site-aware DNS service record lookups and caching of closest dc. The plugin uses the public locator API provided by most modern Kerberos implementations.

## PREREQUISITES
MIT Kerberos (at least version 1.5) or Heimdal Kerberos (at least version 1.0) is required.

The plugin queries the winbindd(8) daemon which needs to be configured and started separately.

The winbind_krb5_locator.so file needs to be manually copied to the plugin directory of the system Kerberos library. For MIT Kerberos this is often: /usr/lib/krb5/plugins/libkrb5/. For Heimdal Kerberos this is often: /usr/lib/plugin/krb5/. Please check your local Kerberos installation for the correct paths. No modification in /etc/krb5.conf is required to enable the use of this plugin.

After copying the locator plugin to the appropriate plugin directory it should immediately be available for use. Users should be able to kinit into their kerberized Windows environment without any modification or servers being put manually into /etc/krb5.conf.

## VERSION
This man page is part of version 4.22.10-alt1 of the Samba suite.

## AUTHOR
The original Samba software and related utilities were created by Andrew Tridgell. Samba is now developed by the Samba Team as an Open Source project similar to the way the Linux kernel is developed.

The winbind_krb5_locator manpage was written by Guenther Deschner.


saned

package: sane-server

title: saned(8)

summary: SANE network daemon

text:
# saned(8)

## NAME
saned - SANE network daemon

## SYNOPSIS
saned [ -a [ username ] ] [ -u username ] [ -b address ] [ -p port ] [ -l ] [ -D ] [ -o ] [ -d n ] [ -e ] [ -h ] [ -B buffer-size ]

## DESCRIPTION
saned is the SANE (Scanner Access Now Easy) daemon that allows remote clients to access image acquisition devices available on the local host.

## OPTIONS
saned recognises the following options:

-a [username], --alone[=username]

is equivalent to the combination of -l -D -u username options. However, username is optional and running user will only be set when specified.

-u username, --user=username

requests that saned drop root privileges and run as the user (and group) associated with username after binding.

-b address, --bind=address

tells saned to bind to the address given.

-p port, --port=port

tells saned to listen on the port given. A value of 0 tells saned to pick an unused port. The default is the sane-port (6566).

-l, --listen

requests that saned run in standalone daemon mode. In this mode, saned will listen for incoming client connections; inetd(8) is not required for saned operations in this mode.

-D, --daemonize

will request saned to detach from the console and run in the background.

-n, --allow-network

allows saned to use network scanners. By default this is forbidden to prevent saned from contacting itself. When enabled, the configuration of the sane-net(5) backend should not mention the address on which saned is listening.

-o, --once

requests that saned exits after the first client disconnects. This is useful for debugging.

-d n, --debug=n

sets the level of saned debug output to n. When compiled with debugging enabled, this flag may be followed by a number to request more or less debug info. The larger the number, the more verbose the debug output. E.g., -d128 will request output of all debug info. A level of 0 produces no output at all. The default value is 2.

-e, --stderr

will divert saned debug output to stderr instead of the syslog default.

-B, --buffer-size=buffer-size

specifies the size of the read buffer used for communication with the backend in KB. Default value is 1MB.

-h, --help

displays a short help message.

## CONFIGURATION
The saned.conf configuration file contains both options for the daemon and the access list.

data_portrange = min_port - max_port

Specify the port range to use for the data connection. Pick a port range between 1024 and 65535; don't pick a too large port range, as it may have performance issues. Use this option if your saned server is sitting behind a firewall. If that firewall is a Linux machine, we strongly recommend using the Netfilter nf_conntrack_sane module instead.

data_connect_timeout = timeout

Specify the time in milliseconds that saned will wait for a data connection. Without this option, if the data connection is not done before the scanner reaches the end of scan, the scanner will continue to scan past the end and may damage it depending on the backend. Specify zero to have the old behavior. The default is 4000ms.

The access list is a list of host names, IP addresses or IP subnets (CIDR notation) that are permitted to use local SANE devices. IPv6 addresses must be enclosed in brackets, and should always be specified in their compressed form. Connections from localhost are always permitted. Empty lines and lines starting with a hash mark (#) are ignored. A line containing the single character ``+'' is interpreted to match any hostname. This allows any remote machine to use your scanner and may present a security risk, so this shouldn't be used unless you know what you're doing.

A sample configuration file is shown below:

\# Daemon options

data_portrange = 10000 - 10100

\# Access list

scan-client.somedomain.firm

\# this is a comment

192.168.0.1

192.168.2.12/29

[::1]

[2001:db8:185e::42:12]/64

The case of the host names does not matter, so AHost.COM is considered identical to ahost.com.

## FILES
/etc/hosts.equiv

The hosts listed in this file are permitted to access all local SANE devices. Caveat: this file imposes serious security risks and its use is not recommended.

/etc/sane.d/saned.conf

Contains a list of hosts permitted to access local SANE devices (see also description of SANE_CONFIG_DIR below).

/etc/sane.d/saned.users

If this file contains lines of the form user:password:backend

access to the listed backends is restricted. A backend may be listed multiple times for different user/password combinations. The server uses MD5 hashing if supported by the client.

## ENVIRONMENT
SANE_CONFIG_DIR

This environment variable specifies the list of directories that may contain the configuration file. On *NIX systems, the directories are separated by a colon (`:'), under OS/2, they are separated by a semi-colon (`;'). If this variable is not set, the configuration file is searched in two default directories: first, the current working directory (".") and then in /etc/sane.d. If the value of the environment variable ends with the directory separator character, then the default directories are searched after the explicitly specified directories. For example, setting SANE_CONFIG_DIR to "/tmp/config:" would result in directories tmp/config, ., and /etc/sane.d being searched (in this order).

## NOTES
saned does not provide confidentiality when communicating with clients. If saned is exposed directly on the network, other users may be able to intercept scanned images, or learn passwords for connecting to saned, with little effort. Client systems should connect to saned through a secure tunnel to the server instead.

saned is not a trusted program and should not run with root privileges.

Refer to /usr/share/doc/sane-backends/saned/saned.install.md for details on configuring saned as a service.

## SEE ALSO
sane(7), scanimage(1), xscanimage(1), xcam(1), sane-dll(5), sane-net(5), sane-"backendname"(5), inetd(8), xinetd(8), systemd(1)

http://www.penguin-breeder.org/?page=sane-net

## AUTHOR
David Mosberger


sanlk-reset

package: sanlk-reset

title: sanlk-reset(8)

summary: host reset program

text:
# sanlk-reset(8)

## NAME
sanlk-reset - host reset program

## SYNOPSIS
sanlk-reset [OPTIONS] action lockspace_name ...

## DESCRIPTION
The sanlk-reset program sets events in specified sanlock lockspaces. Events are defined to cause sanlk-resetd on another host to:

- use wdmd/watchdog to reset the host

- use /proc/sysrq-trigger to reboot the host

Both hosts must be operational and have continued access to a common lockspace for the reset request to succeed. After setting the event, the sanlk-reset program monitors the host status in the sanlock lockspace until the target host is dead.

The sanlk-reset program can also be run on the same host as sanlk-resetd to update which lockspaces the local sanlk-resetd is watching for events.

## OPTIONS
--version, -V

Print version.

--help, -h

Print usage.

### Reset another host
The event is set in each lockspace specified. The target host may have a different host id in each lockspace.

sanlk-reset reset lockspace_name:host_id ...

--host-id, -i num

Host id to reset. (Use only with single lockspace name.)

--generation, -g num

Generation of host. (Use only with single lockspace name.)

--sysrq-reboot, -b 0|1

Enable/Disable (1/0) use of /proc/sysrq-trigger to reboot.

--resource-mode, -R 0|1

Resource leases are used (1) or not used (0) to protect storage.

--native-timeout, -t num

Disable native timeout by setting to 0.

### Update the local sanlk-resetd

to watch new lockspaces for reset events:

sanlk-reset reg lockspace_name ...

to not watch lockspaces for reset events:

sanlk-reset end lockspace_name ...

to clear all lockspaces being watched:

sanlk-reset clear all

## SEE ALSO
sanlk-resetd(8) sanlock(8) wdmd(8)


sanlk-resetd

title: sanlk-resetd(8)

summary: host reset daemon

text:
# sanlk-resetd(8)

## NAME
sanlk-resetd - host reset daemon

## SYNOPSIS
sanlk-resetd [OPTIONS] lockspace_name ...

## DESCRIPTION
The sanlk-resetd daemon gets events from specified sanlock lockspaces. Events are defined to cause sanlk-resetd to:

- use wdmd/watchdog to reset the host

- use /proc/sysrq-trigger to reboot the host

The sanlk-reset program can be run on another host to request that sanlk-resetd reset the host it is running on. Both hosts must be operational and have continued access to a common lockspace for the reset request to succeed. After setting the event, the sanlk-reset program monitors the host status in the sanlock lockspace until the target host is dead.

The sanlk-reset program can also be run on the same host as sanlk-resetd to update which lockspaces the local sanlk-resetd is watching for events.

## OPTIONS
--version, -V

Print version.

--help, -h

Print usage.

--foreground, -f

Don't fork.

--daemon-debug, -D

Enable debugging to stderr and don't fork.

--sysrq-reboot, -b 0|1

Enable/Disable (1/0) use of /proc/sysrq-trigger to reboot.

--sysrq-delay, -d sec

Delay this many seconds before using /proc/sysrq-trigger.

--resource-mode, -R 0|1

Resource leases are used (1) or not used (0) to protect storage.

## SEE ALSO
sanlk-reset(8) sanlock(8) wdmd(8)