Clarification regarding the status of Identity Management for Unix (IDMU) & NIS Server Role in Windows Server 2016 Technical Preview and beyond


Note: The original blog article has been updated to address a number of questions we received and to further clarify what has been removed and what remains. Due to the Active Directory Documentation Blog being retired in October 2015, the comments have been removed. Please post your questions/comments in the Directory Services TechNet Forum.

With Windows Server 2012 R2, Microsoft announced the deprecation of the Identity Management for Unix (IDMU) and NIS Server role which will not be included starting with Windows Server 2016 Technical Preview. This has been documented in a couple of places:
In this blog article we will go into further detail and answer questions on what this means to you when you are migrating/upgrading to Windows Server 2016 and are using Identity Management for Unix/NIS Server with Windows Server today.
 

Why did Microsoft remove IDMU/NIS Server role from Windows Server?

After carefully reviewing and considering the feature usage, industry trends, availability of native Active Directory options on Linux/Unix and security concerns of NIS in general, the decision was made to remove the functionality from Windows Server. We announced the deprecation in the development phase of Windows Server 2012 R2 and have removed it from Windows Server 2016.
 

What IDMU/NIS Server components are removed from Windows Server 2016?

IDMU/NIS Server has been removed, specifically the following components are no longer included with Windows Server 2016:

-          Network Information Service (NIS) Windows Server role

-          The Unix Attributes plug-in for the Active Directory Users and Computers Management Console (MMC) snap-in

Note: RFC2307 attributes (e.g. GID/UID etc.) in Active Directory continue to exist. See below for further details.
 

I am using Windows Server IDMU/NIS Server role today, what should I do?

We recommend to start planning for alternatives, for example: native LDAP, Samba Client, Kerberos or other non-Microsoft options. Existing Windows Server 2012 R2 or earlier deployments will continue to be supported in accordance with the Microsoft Support lifecycle.
 

What happens when I have the NIS Server Role installed and try to upgrade to Windows Server 2016?

If you try upgrade to Windows Server 2016 from a Windows Server that runs any of the Identity Management for Unix (IDMU) components, the upgrade will stop and you will be prompted to remove the IDMU components as explained in “Installing or removing Identity Management for UNIX by using a command line”.
 

Can I continue to use the GID/UID (RFC 2307) attributes I am using today with Active Directory after I upgrade to Windows Server 2016?

Active Directory does not remove the populated UID/GID Active Directory attributes during the upgrade to Windows Server 2016 from Windows Server 2012 R2. The attributes will remain part of your Active Directory setup. These attributes were introduced as part of RFC 2307 support that was added in Windows Server 2003 R2.  
For example, you may require the RFC 2307 attributes in combination with Network File System (NFS) Server (which does not require NIS Server role to be installed on Windows Server) to map the identity.
 

How do I continue to edit the GID/UID RFC 2307 attributes now that the Unix Attributes Plug-in is no longer available for the Active Directory Users and Computers MMC snap-in?

There are a couple of ways to continue to administer the attributes:

1.       Active Directory Users and Computers MMC snap-in

1.       Open Active Directory Users and Computers.

2.       From the dropdown menu, select View -> Advanced Features:

3.       Open the properties of a User, Group or Computer Object

4.       Navigate to “Attribute Editor” tab to edit the following attributes:

    1.                                                              uidNumber
    2.                                                              gidNumber
    3.                                                              Loginshell
    4.                                                              unixHomeDirectory
    5.                                                              MemberUid
    6.                                                              ipHostNumber

 

2.       Active Directory Administrative Center

1.       Open Active Directory Administrative Center

2.       Navigate to a User, Group or Computer Object

3.       Navigate to Extensions

4.       Navigate to “Attribute Editor” tab to edit the following attributes:

    1.                                                              uidNumber
    2.                                                              gidNumber
    3.                                                              Loginshell
    4.                                                              unixHomeDirectory
    5.                                                              MemberUid
    6.                                                              ipHostNumber

3.       Scripts (preferred method for bulk operations and automation)

·         Using Active Directory PowerShell Cmdlet:

o   Below is sample code to query/configure the various attributes

Import-Module ActiveDirectory

#To query Unix Properties of a User Object

$username = "guest"

Get-ADUser $username -Properties * | Select SamAccountName, msSFU30NisDomain,uidNumber, unixHomeDirectory, loginShell, gidnumber, @{Label='PrimaryGroupDN';Expression={(Get-ADGroup -Filter {GIDNUMBER -eq $_.gidnumber}).SamAccountName}}

#To query Unix Properties of a Group object

$groupname = "Unix Sample Group"

Get-ADGroup $groupname -Properties * | Select SamAccountName, msSFU30NisDomain,gidnumber, @{Label='Members';Expression={(Get-ADUser -Filter {GIDNUMBER -eq $_.gidnumber}).SamAccountName}}

#To query Unix Properties of a Computer Object

$computername = "server123"

Get-ADComputer $computername -Properties * | Select SamAccountName, msSFU30NisDomain,ipHostNumber, msSFU30Aliases

#Set unixHomeDirectory on a user (replace this with any of the attributes you’d like to set)

$username = "guest"

set-ADUser $username -Replace @{unixHomeDirectory="/usr/sbin/guest"}

 

o   Below, is sample output from the sample code above

Sample output from the PowerShell Script:

SamAccountName    : Guest

msSFU30NisDomain  : woodgrove

uidNumber         : 10001

unixHomeDirectory : /usr/sbin/guest

loginShell        : /bin/sh

gidnumber         : 10001

PrimaryGroupDN    : Unix Sample Group

 

SamAccountName   : Unix Sample Group

msSFU30NisDomain : woodgrove

gidnumber        : 10001

Members          : {Administrator, Guest}

 

SamAccountName   : Server123

msSFU30NisDomain : woodgrove

ipHostNumber     : {10.2.2.2}

msSFU30Aliases   : {bla, unixtestclient}

 

·         Using NFS PowerShell CmdLet Set-NfsMappedIdentity:  Please see the following page for more information: Set-NfsMappedIdentity.

·         Using VBScript: There is also a TechNet blog article from a while back that has some additional detail to configure and populate the attributes in Active Directory http://blogs.technet.com/b/dsix/archive/2009/04/16/integrating-unix-client-in-active-directory-using-ldap-part-i.aspx.

 

What Active Directory Attributes did the Unix Attribute tabs expose in the Active Directory Users and Computers MMC snap-in prior to Windows Server 2016?

The following Active Directory Attributes were configurable from the Unix Attributes tabs in Active Directory Users and Computers prior to Windows Server 2016. This table is provided as a reference and with Windows Server 2016 all of these attributes can be modified using the methods described as part of this blog article above:
Dialog name
AD Attribute
RFC2307 attribute
Example
User object
Group object
Computer object
UID
uidNumber
X
1000
X
 
 
Login Shell
Loginshell
X
/bin/bash
X
 
 
Home Directory
unixHomeDirectory
X
/home/username
X
 
 
Primary Group name/GID
gidNumber
X
10002
X
X
 
Members
MemberUid
X
Administrator
 
X
 
iphostnumber
ipHostNumber
X
10.2.2.2
 
 
X
NIS Domain
maSFU30NisDomain
 
“example”
X
X
X
Members
msSFU30PosixMember
 
CN=Group,CN=Schema, CN=Configuration, DC=Woodgrove,DC=Local
 
X
 
Name
msSFU30Name
 
“Server123” or “Administrator” or “unix group”
X
X
X
Computer Aliases
msSFU30Aliases
 
Alias1; alias2
 
 
X
 
Thank you for reading this article!

Note: Questions and comments are welcome. However, please DO NOT post a request for troubleshooting by using the comment tool at the end of this post. Instead, post a new thread in the Directory Services Technet forum. Thank you!

Comments (15)

  1. We hear you, and thanks again for the feedback. The default schema is of course fully supported, and the UNIX attributes are included by default. We cannot say for sure what the default schema will include in future releases, but there are no plans to
    change the inclusion of the UNIX attributes.
    To be more clear about this whole issue, IDMU will continue to be supported throughout the support lifecycle of Windows Server 2012 R2. But we want customers to be aware of the deprecation so they can make alternative plans before product support ends and avoid
    any kind of fire drill.

    Justin [Active Directory Documentation Team]

  2. Thanks for the feedback Justin and Lee. I am sharing your comments with the engineering team.

    The schema is not touched, e.g. data that was added to AD will still be there and customers can still use the AD Users console with the plug-in installed to continue managing these identities from Windows Server 2012 R2.

    As for rationale, the decision was made after reviewing customer data and available functionality. Given other alternatives available (native LDAP, Samba Client, Kerberos, or non-Microsoft options), the decision was made to stop investing in this specific feature.

    Thanks,
    Justin [Active Directory Documentation Team]

  3. Hi David,
    Thanks for asking. I’m told by the engineering team that the recommendation is to use native LDAP, Samba Client, Kerberos, or non-Microsoft options on Unix/Linux systems to integrate with Active Directory for password management. There are also third-party
    solutions but those are not tested by Microsoft so we don’t make any specific recommendations about them.

    Justin [Active Directory Documentation Team]

  4. Jim Cottrell, thanks for the feedback. It has been shared with engineering team and they are investigating options. I will post any updates here.

    CH Liu, I am not aware of any docs we have for RH integration. As far as I know, it’s not something we test or have guidance for.

    Thanks,
    Justin [Active Directory Documentation Team]

  5. David DeLeon says:

    Hello – What will be the supported method of integration with Unix/Linux on Server 2012 R2 in lieu of IDMU?

  6. Justin P says:

    Uhhhh… what is the rationale for this? Are you aware that there are a LOT of large customers out there using AD for LDAP for UNIX identities?

  7. Justin P says:

    Also, if it removes IDMU does it just remove the tools? Or will it nuke the schema attributes as well?

    Meaning, can we still use AD to host schema attributes like UID/GID without the native tools?

  8. Lee M says:

    This seems like a very disruptive unilateral decision which will impact greatly the acceptance of Active Directory as the source of truth directory service in an organisation

  9. Justin P says:

    Thanks. As far as sheer numbers go, I’m sure it’s not a large % but there are some very large customers (like, Microsoft large) using AD for UNIX LDAP. So it’s good they won’t have to back out of the AD setup. I assume MS will still fully support the schema,
    too.

    As far as extending the schema, does Win2k12R2 and beyond add the UNIX attributes by default? Or do they need to be built out manually?

    As I’m sure you know, AD is pretty ideal for LDAP for a variety of reasons, so I’d hate to see MS abandon this.

  10. Ben says:

    Is there going to be more detail of exactly what services will no longer be in available? I understand an LDAP + KRB5 configuration should still work post 2012 R2 but how will it be managed? Will the attributes need to be updated via PowerShell / ADSI
    Editor? Is the "Unix Attribute" tab actually going away?

    We recently decided to utilize AD as our single source of authorization and authentication source. However that may have to be recant if this decision will impact our daily operations.

    Over the past few years we’ve closed on the % of Windows vs Linux and decisions like this are painful.

  11. Adam Thompson (Avant Systems Group) says:

    I understand removing the NIS server, since I haven’t seen anyone using NIS in a mixed-mode environment since Win2003.
    But removing the UNIX Attributes tab from Users & Computers is one of the most self-destructive things I’ve seen Microsoft do this decade. I’ve been recommending UNIX shops use AD as their master directory for a while now, because AD is a stable, functional,
    easy-to-manage LDAP directory that fully supports the various RFCs and de-facto schema standards.
    If the UNIX Attributes tab goes away, am I supposed to tell admins that they need to use ADSI Edit to manage UNIX GIDs and UIDs? Not gonna happen.
    WS2012R2 is only now getting traction in my part of the world, but this is a good way to kill off a smallish but still significant portion of customers (and licenses).

  12. CH Liu says:

    We are deploying new 2012 AD now and also wanted to integrate Redhat Linux 6 with 2012 AD. Is there any document we can follow from Microsoft side? We have steps and procedure to follow on Redhat end of configuration. However, I can not find any technical
    article/document regrading 2012 AD change for this integration. I would appreciate it if someone can suggest the right technical article/doc on Windows 2012 AD side of configuration since IMU is being deprecated.

  13. Jim Cottrell says:

    Justin. After reading a bit, I am only partially distressed. Nobody really like NIS; we’d all just as well see it go. We fully endorse using Native LDAP support. However, we *need* the RFC2307bis attributes to be supported in the scheme. Furthermore, if
    MSFT expects Linux/UNIX users to use Active Directory for Identity management, the UNIX Attributes Tab needs to be retained. It’s one thing (easy) for Help Desk people to add UID, GID, Shell and Home Directory when adding a user; it’s another thing entirely
    (unreasonable) to expect them to add them with ldapmodify. Current Best Practice in the Red Hat world is Authentication via Kerberos (or Winbind or SSSD), and Identity Management via LDAP via SSSD. Bottom Line: Nuke most of IDMU, but *keep* the Schema and
    the UNIX Attributes Tab.

  14. John DIto says:

    This is a VERY bad idea. The UNIX attributes are widely used by shops moving from OpenLDAP to AD. Im currently moving a very forward thinking company from OpenLDAP to AD and I NEED the Unix attributes tab.

    Microsoft should understand the many application of these attributes and their value in the Enterprise.

    Best, John

  15. Jeremi Albrizio says:

    So does Microsoft want everyone to use another product?
    We have to start looking for another solution due to this being removed from AD.

Skip to main content