Tag Info

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 ...


15

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 ...


14

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 ...


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 ...


7

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 ...


6

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

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: ...


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

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 ...


3

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


3

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.


3

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 ...


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

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 ...


2

While Hiera is the best way and is duely accepted, I'd like to add for completeness' sake: There is a syntax to do just this override you had in mind: node "node1.systems.private" { include "org::default" Sssd::Domain<| title == 'LDAP' |> { simple_allow_groups => ['SysAdmins','AppAdmins'], } } Note that this syntax also serves to ...


2

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 ...


2

You misspelled sufficient as sufficeint in /etc/pam.d/system-auth. And you don't seem to be using sssd directly; you called pam_ldap.so instead of pam_sss.so.


2

Which SSH authentication method are you using? Are you typing in your password, or trying to use Kerberos ticket-based authentication (gssapi-with-mic or gssapi-keyex)? The “decrypt integrity check failed” message could come from two sources. If you give it the wrong password (your password doesn’t match the keys for your principal in the KDC), you’d get ...


2

Ok, if your user is local "root" on that machine he can do anything on that machine. Blocking "su -" would not really prevent anything. "su -" trumps everything, it is inherently local. For something you want to accomplish you need to design your HBAC rules against service called 'su-'. The main thing here is no user account should have local root on the ...


2

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 ...


2

I think you did it correctly, probably it's working and you don't know it. By default, the getent for all the users don't show the IDs, but doing a getent passwd username returns what you expecting. Check again


2

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 ...


2

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 ...


2

You want getent: getent passwd 1582 That'll look up entries via your configured nss config. If you've configured it to use LDAP, then it'll use LDAP.


2

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] ...


2

sssd ships unconfigured. You must create at least one domain before starting the service. See the documentation for full information on using sssd.


2

According to that log, it looks like SSSD's LDAP provider crashed and had to be restarted. That's why you got access-denied. See specifically: (Fri Jun 21 22:42:46 2013) [sssd[be[default]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_BIND] (Fri Jun 21 22:42:46 2013) [sssd[be[default]]] [simple_bind_done] (0x2000): Server returned control ...


2

Since you don't need the password synchronization functionality you could, either remove the "Password Synchronization" role service using the Server Manager GUI, or from a PowerShell w/ an Import-Module Servermanager already run execute the Remove-WindowsFeature ADDS-Password-Sync command. (Source: http://technet.microsoft.com/en-us/library/cc725709.aspx) ...


2

I found the solution to the problem. By running sssd -i -d 4 and trying to log in on a different console, I saw that START TLS was where the login failed. Apparently Red Hat and Fedora by default use TLS. The server does not have TLS (we don't have enough time right now). To disable TLS edit /etc/sysconfig/authconfig on the client machine and update ...



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