SSSD, NIS and identity management for UNIX

  • 2.4K Views
  • Last Post 23 November 2015
danj posted this 20 November 2015

Hi all   I’m doing some work for a client who are moving a bunch of stuff to an IaaS cloud. The cloud provider intends to integrate Linux (RHEL 6.4) with active directory using SSSD. To do this they want to install Identity Management for UNIX (IDMU) on the client’s DCs to allow the linux boxes to use NIS. Problem is IDMU is deprecated in 2012 R2 and removed from 2016:   http://blogs.technet.com/b/activedirectoryua/archive/2015/01/25/identity-management-for-unix-idmu-is-deprecated-in-windows-server.aspx   which means there would be a hard dependency stopping upgrade to Server 2016 active directory next year, something I am not happy with. MSFT do not appear to be supporting any NIS server integration going forward.   Seems odd that the developers of SSSD would not know about this NIS dependency or have a way around it. I’m not that familiar with SSSD but given that (so the cloud provider’s tech says) they are using NIS for group lookups etc I would have thought SSSD would have a solution for this.   Has anyone any experience of this, or know what the options might be?   Dan Johnson

Order By: Standard | Newest | Votes
kurtbuff posted this 20 November 2015

SAMBA comes to mind as an alternative.

Kurt

show

moter posted this 20 November 2015

So as a Windows guy I had to google NIS to make sure I knew what you were talking about.  Essentially NIS is a precursor to AD and LDAP that Sun came up with long before AD and LDAP.

 

I also use SSSD and Kerberos to join linux to our 2012 R2 AD, authenticate users, apply group policies to linux, and I can look up groups just fine.  None of which uses or requires NIS.  It’s a bit unclear to

me who really depends on NIS here.  AD, SSSD, and Kerberos definitely don’t.  Something legacy that the cloud provider requires maybe?

 

Todd

 

show

gkirkpatrick posted this 22 November 2015

SSSD is an identity/authn daemon sort of like winbind that interfaces to the host through PAM and NSS configuration. I don't understand why they would be using NIS. You can configure both SSSD and winbind to use LDAP for name resolution.

Note that while winbind supports NTLM, SSSD doesn't...

-gil

show

gkirkpatrick posted this 22 November 2015

SSSD is an identity/authn daemon sort of like winbind that interfaces to the host through PAM and NSS configuration. I don't understand why they would be using NIS. You can configure both SSSD and winbind to use LDAP for name resolution.

Note that while winbind supports NTLM, SSSD doesn't...

-gil

show

Batz_10K posted this 23 November 2015

Sssd doesn't require NIS. (Actually NIS is known to be insecure and is generally deprecated in the Unix world). What they probably want IDMU for is to be able to set/manage the Unix UID/GID (The linux/unix equivalent to the user/group SID, without the machine-specific part - it's an integer 0-65536 and must be unique to each user). IDMU includes a user property pane in ADAC to manage these (along with the Unix home directory and default shell attributes). It's possible to manage these without that properties panel by setting the attributes directly with PowerShell or some other tool (they are - uidNumber,gidNumber,UnixHomeDirectory and LoginShell if using the rfc2307bis schema - (AD schema version 31)). SAMBA does have some mechanisms for deriving these from the SID, but it's possible to get collisions using that mechanism, so I wouldn't rely on it. If they are comfortable using PS or some other tool to manage these, then I don't see any reason why you couldn't upgrade to 2016.

Cheers

show

danj posted this 23 November 2015

Thanks all for responses. I already wrote a powershell GUI tool to create users according to their business rules so adding fields to expose LDAP attributes is no issue. It's more that I need to ensure that all info they are getting through NIS is available in other ways. So does SSSD pickup the shell and home dir using LDAP? I got an excellent response from Abhi off-list which explains how SSSD manages authorization so that is covered.

Problem is this is a managed service and so I can't get in their lab to test it, or replicate their setup in mine.

Dan

show

Batz_10K posted this 23 November 2015

Yes, sssd uses LDAP to retrieve the login shell and home directory. There's a mapping feature so that you can configure which attributes are used to retrieve the login shell and home directory.

Cheers

show

jeremyts posted this 23 November 2015

A lot of people tend to get very confused with this, which is why they think they need the identity management for UNIX components. The problem when it comes to Server for NIS Tools, is that it not only creates the NIS integration, which is not needed, it "completes" the UNIX integration. Whilst the UNIX attributes have been part of the schema since Windows Server 2003 R2, which are RFC2307/RFC2307bis compliant, without the correct NIS integration the UNIX Attributes tab in Active Directory Users and Computers doesn't work because the NISPROP.DLL file, the DLL behind the UNIX Attributes tab, expects the NIS domain information to be present in Active Directory. If the NIS objects are missing, the fields in the tab remain disabled, which means that the ADUC MMC cannot be used to manage the UNIX integration. It's a catch 22 situation. If you're not using the Unix attributes or you don't need to view them in Active Directory Users and Computers, you don't need to worry about this. You've already mentioned that you're scripting it with PowerShell, so nothing is required.

I like the SSSD integration, but am finding that people tend to go with the Winbind integration for NTLM support as Gil mentions.

Red Hat have a great whitepaper that will show you all the different integrations and their pros and cons: http://www.redhat.com/en/resources/integrating-red-hat-enterprise-linux-6-active-directory

Work out what "services" you need, and therefore which binding and auth mechanism is right for you.

The Unix attributes themselves are not being deprecated, which at the end of the day is the only "AD" component you will/may need.

The biggest catch though is that the Unix attributes are not indexed by default, which causes certain LDAP queries to be expensive, inefficient and time consuming. Your mileage may vary, but you should monitor your LDAP queries as you may need to index the UID, uniqueMember and memberUID attributes.

Cheers,
Jeremy

show

Close