Hot answers tagged

28

Here is a couple of shell scripts that will install and configure openldap on a server and install and configure sssd for user authentication against the LDAP-server. One that installs the LDAP-server with groups, users etc. #!/bin/sh ########################################################### # Install LDAP-server ...


20

An note to add to this for google searchers - we had the same issue where no matter what we did, the nfs mount would not map the user ids correctly. The issue was idmapd had cached the incorrect ids from the faulty configuration, and no fixing of the configuration would sort it. The command on centos to fix this was nfsidmap -c (clear cache). Hopefully ...


17

Solved! I happened to notice this line in /var/log/messages on my NFS server when I was attempting to mount an export from the remote client: Feb 28 15:54:02 storage1 rpc.idmapd[1651]: nss_getpwnam: name 'nobody' does not map into domain 'localdomain' This caused me to look at the first few lines of /etc/idmapd.conf: [General] #Verbosity = 0 # The ...


9

You should use TCP ports 389 and/or 636. Port 636 is for LDAPS, which is LDAP over SSL. Encryption on port 389 is also possible using the STARTTLS mechanism, but in that case you should explicitly verify that encryption is being done. Microsoft's KB article says: Start TLS extended request LDAPS communication occurs over port TCP 636. LDAPS ...


8

There are some tricky considerations to make everything works out-of-the-box. FreeBSD only supports sssd version 1.9.6 at this moment. So there's no support for Enterprise Principal Names. If you have a domain with non matched UPNs it will fail to login, since the Kerberos authentication will fail during the process, even with FreeBSD supporting Enterprise ...


7

After you have added ipa_dyndns_iface = eth0 in that pastebin i see sssd recognize your ip as multicast: "(Tue Jul 9 10:00:01 2013) [sssd[be[example.us]]] [ok_for_dns] (0x0200): Multicast IPv4 address 172.25.50.227" in the piece of code Jacob wrote where he would test for looback addresses, multicast addresses e.t.c. not to report to dns you will find ...


5

Come up with a better user naming scheme... (or force "kdm" to use different login credentials) I've had to learn this lesson over the years as I inherited commercial Unix systems with three-letter usernames. Moving those servers to Linux exposed conflicts with system service accounts. The worst case was Randy P. McDonald, or userID "rpm". The RPM package ...


5

What you deal with is called enterprise principals. You have a single AD domain but users can have additional user principal names (UPN) associated, so in addition to XXXX.LOCAL they can have XXXX.COM and use user@XXXX.COM in place of user@XXXX.LOCAL. SSSD does support enterprise principals starting with 1.10. There were few bugs in the implementation that ...


5

I would use Hiera: http://docs.puppetlabs.com/hiera/latest/ Hiera lets you decouple your variable data from your Puppet manifests. Hiera, as the name implies, is hierarchical, allowing for some interesting ways to override, as well as combine, variable data. First, modify your sssd:: domain declaration to perform Hiera lookups for the parameters: ...


5

Without a credentials cache any offline authentication will fail. Add the sss_cache -E to your startup scripts. If you do wipe the cache on reboot then until the domain servers can be contacted no users will be able to authenticate to that machine using domain credentials until it is able to.


4

I have outlined all the steps necessary to get this up and working. There are a series of bugs regarding the install of the packages. All of the underlying software works great, but there are a few steps you have to take to make things work: http://funwithlinux.net/2014/04/join-ubuntu-14-04-to-active-directory-domain-using-realmd Short version: Add the ...


4

sssd is probably the more "forward thinking" option to go with. To that extent, the other answers are correct. That said, sssd does not completely supersede the features of nslcd, contrary to popular opinion. The primary (situational) advantage of nslcd over sssd is that you can write a custom authz query with parameter substitution: pam_authz_search ...


4

Client Setup I've referred to Arlukin's answer quite a bit but I thought a pared-down version of the client setup would be helpful. Once you've got your certificates set up just do the following: yum install sssd pam_ldap chkconfig sssd on authconfig \ --enablesssd --enablesssdauth --enablecachecreds \ --enableldap --enableldaptls --enableldapauth ...


4

sssd was added to RHEL 5 with the RHEL 5.6 service pack. Bring the systems up to date, (the current release is RHEL 5.11) and you will then have access to it. And, do not run RHEL without a subscription.


3

Try to put this row at the beginning of your /etc/pam.d/sshd file. auth sufficient pam_sss.so


3

Here's my final solution, coded in ansible: - name: Disable ldap users ini_file: dest=/etc/sssd/sssd.conf section='nss' option=filter_users value={{ filter_ldap_users | join(",") }} register: sssd_conf_users - name: Disable ldap groups ...


3

An easiest way is to start capturing packets on ipaserver.mydom.example.com, listening for the traffic coming from loginhost.mydom.example.com. For example, with tshark (console version of wireshark) you can do both interception and analysis at the same time: tshark -w /tmp/t.pcapng -W n -P -V -x host loginhost.mydom.example.com | tee /tmp/t.log Once ...


3

You haven't configured your access provider. You have access_provider = ldap but you don't have ldap_access_filter configured anywhere. From the man page on the ldap_access_filter option: If access_provider = ldap and this option is not set, it will result in all users being denied access. I would just remove the access_provider option altogether ...


3

Try below settings, They work pretty well in my environment. Make changes to /etc/sssd/sssd.conf [root@localhost ~]# cat /etc/sssd/sssd.conf |grep -v ^# |grep -v ^$ [sssd] config_file_version = 2 reconnection_retries = 3 sbus_timeout = 30 services = nss, pam domains = default [nss] filter_groups = root filter_users = root reconnection_retries = 3 [pam] ...


3

From http://docs.fedoraproject.org/en-US/Fedora/14/html/Deployment_Guide/chap-SSSD_User_Guide-Configuring_Domains.html: Enumeration means that the entire set of available users and groups on the remote source is cached on the local machine. When enumeration is disabled, users and groups are only cached as they are requested. For performance reasons, it ...


3

There is an option in the ldap configuration to ignore ldap lookups for certain user ids. In /etc/ldap.conf nss_initgroups_ignoreusers root,ldap,named,avahi,haldaemon,dbus,radvd,tomcat,radiusd,news,mailman There is also this configuration value in the sssd config file filter_users, filter_groups (string) Exclude certain users from being fetched ...


3

Please check Simo Sorce's answer in a related Bugzilla, it pretty nicely summarizes Linux security model and what you can or cannot do as a local root: Hi Swartz, the root account on any linux machine is all powerful and can do anything it wants, it can even create local users and impersonate them w/o issue. I suggest you take the time to ...


3

From the man page of sssd-ad: By default, the AD provider will map UID and GID values from the objectSID parameter in Active Directory. For details on this, see the "ID MAPPING" section below. If you want to disable ID mapping and instead rely on POSIX attributes defined in Active Directory, you should set ldap_id_mapping = False


3

You can use the unique overlay to achieve this. See chapter 12.16 of the OpenLDAP manual and man slapo-unique (unfortunately, both still only refer the old-style configuration in slapd.conf, not the cn=config online configuration).


3

The only option to achieve this is to create an LDAP filter string to be used by the ldap_user_search_base config parameter (syntax: search_base[?scope?[filter][?search_base?scope?[filter]]*]). This must be a valid RFC 2254 filter, and will likely somehow incorporate your ldap_access_filter into the ldap_user_search_base. The reason for this is that ...


3

Well my premises about the workings of PAM were right. The pam_sss.so module was expecting the argument forward_pass to relay to password for other PAM modules, as the pam_unix.somodule. So just putting this option do the job. The resultant line was: auth sufficient /usr/local/lib/pam_sss.so forward_pass Which ended in another ...


3

As long as it LDAP auth only (and not AD/Kerberos etc.), 389 should be sufficient.


2

I would really like to hear what you mean by "real AD groups" when talking about SSSD. The newer versions of SSSD don't require the groups to have POSIX attributes and mostly read the group memberships from TokenGroups if the AD provider is used. Also, in RHEL-7.1 (upstream 1.12+), the SSSD gained the capability to do access control checks using GPO ...


2

I'm not I can give a more qualified answer without seeing the sssd debug logs, but the bug report you're referring to only had performance implications, not functional. The reason you're able to su to the account from root is that the PAM stack normally includes pam_rootok.so module that bypasses authentication with pam_sss. Given the auth from root works, ...


2

because the sssd cache is not stored in ram, so it survives reboots; do as Brian recommends and add that command to the rc.local, for instance. For more info about the sssd caches read man sssd.conf on your system.



Only top voted, non community-wiki answers of a minimum length are eligible