This page includes user contributions on the topic of Unix interoperability. If you have a contribution on this topic, please send an email to help@uw.edu for the Microsoft Infrastructure service. We’d love to include your knowledge for other’s benefit.
Contributor: Unknown
PowerBroker Identity Services
By default (without using a GPO or changing the PBIS registry in PBIS Open), one must prefix the username with “netid\” to logon. To remove the domain prefix (netid\), you need to set the parameter “AssumeDefaultDomain” to the value 1. This can be done either using a GPO or change the PBIS registry (in PBIS Open). This setting is this shown as “Lsassd: Prepend default domain name for AD users and groups” in the Group Policy UI.
Contributor: Sai Lun (Alan) Li
At CSDE, we have a GPO that applies to computers who join to the NETID domain.
The settings are listed here:
Computer Configuration \ Unix and Linux Settings \ BeyondTrust Settings \ PBIS \ Authorization and Identification \ Lassad:Prepend default domain name for AD users and groups = true
Computer Configuration \ Unix and Linux Settings \ BeyondTrust Settings \ PBIS \ Authorization and Identification \ Lassad:Sysetm time synchronization = true
Computer Configuration \ Unix and Linux Settings \ BeyondTrust Settings \ PBIS \ Authorization and Identification \ Lassad:Home directory path prefix = /homes
Computer Configuration \ Unix and Linux Settings \ BeyondTrust Settings \ PBIS \ Authorization and Identification \ Lassad:Home directory path template = %H/%U
Computer Configuration \ Unix and Linux Settings \ BeyondTrust Settings \ PBIS \ Authorization and Identification \ Lassad:Login shell template = /usr/bin/tcsh
Computer Configuration \ Unix and Linux Settings \ BeyondTrust Settings \ PBIS \ Logon \ Allow logon rights = NETID\saili, NETID\mbw, NETID\uw_csde_ad_acct_admins, NETID\uw_csde_mailmansync_unix
Computer Configuration \ Unix and Linux Settings \ BeyondTrust Settings \ PBIS \ Logon \ Create home directory for user account at logon = false
Computer Configuration \ Unix and Linux Settings \ BeyondTrust Settings \ PBIS \ Group Policy Agent \ User policy loopback processing mode = Replace mode
Computer Configuration \ Unix and Linux Settings \ Message Settings \ Mesasage of the Day \ Message of the day (\etc\motd) = “You are logged on to the NETID domain”
Using this GPO, we can restrict who can log on to our Unix/Linux servers and where the user’s UNIX homedirectory comes from.
This GPO applies to computer that has PBIS Enterprise installed and with a valid license. Using PBIS Open (free version) one can still use NETID authentication for user logon. However, PBIS GPO doesn’t work for PBIS Open clients.
PBIS Open installed computers can still use some of the PBIS Enterprise GPO settings to restrict user logons and set Unix HomeDirectory and LoginShell by changing the PBIS registry using the tools regshell (installed in /opt/pbis/bin).
CSDE has a sample PBIS registry file and is available to anyone on campus who is interested in using PBIS Open to join Unix/Linux/Mac computers to UWWI domain. The registry file is a text file and can be modified by any text editor. After modifying the file, it can be imported into the PBIS registry by running the regshell command.
Although PBIS Open doesn’t give you the right uid/gid in UWWI Active Directory, I am still able to connect to the Samba Nebula Storage (//files.nebula.washington.edu/groups/csde_office) with read/write permissions on a Mac that runs PBIS Open.
I imagine this would work the same for the Student UDrive storage which will be very useful for UW student users logging on a Mac that uses PBIS Open to join to the UWWI domain,
Contributor: Richard L Ketcham
I have configured CentOS 7 linux with sssd (“Redhat System Security Services Daemon”) to participate in the UWWI, that is, the UW NetID Microsoft Active Directory.
With the linux host so configured and joined to the UWWI Windows domain, any user with a UW NetID can log in with his netid and password, with no prior user specific local configuration. A home directory is auto-created for the user upon first login, and the user’s UW U-Drive is auto-mounted under his home directory at each login and unmounted at log out, using his AD single-sign-on credentials.
SSSd should also support AD Group-Policy access control, but so far I have not been able to make this work within the UWWI domain.
My steps in setting up and configuring an sssd based UWWI linux client are documented here:
Linux Integration with the UWWI Microsoft Active Directory using CentOS7 with SSSD
Following up on my sssd experiments, I was unsuccessful at implementing access control by GPO (ad_gpo_access_control) or by the simpler, more direct, group-based access control mechanism, ad_access_filter. Upon further investigation, I find a fundamental underlying problem with any group based policy: The UWWI denies read access to most user attributes, and in particular, to the attribute that is needed for access control by group: “memberOf”. I describe probing of the UWW to see what can and what cannot be accessed in the linked page: Poking the UWWI
Read access of users’ memberships is denied, but we can enumerate members of our UW Group Services groups. Therefore we can look up users’ memberships in reverse, by querying our group object. I haven’t found any such capability to exist in sssd, but there are many possible ways to script this. The script must make the query over an authenticated connection and synchronize the enumerated member list to a local database or file, and then we need a way of hooking this downloaded member list into the Linux authentication and authorization mechanism.
For the secure connection, I could have used ldap gssapi with my machine credentials, as I did in my previous post, but instead I will use this script I found on the IAM Group Service wiki which uses a client certificate.
I found a pair of pam modules that do the trick of matching user names against list files.
More details here: UW Groups Workaround
Contributor: Stefani P. Banerian
In working to be able to use ansible to manage servers and workstations and other devices, some of the target machines were on the netid domain.
with some effort, I was able to find that the following enabled me to at least perform a kinit
[realms]
NETID.WASHINGTON.EDU = {
admin_server = _kerberos._tcp.dc._msdcs.netid.washington.edu
kdc = sidious.netid.washington.edu
kdc = maul.netid.washington.edu:88
default_domain = NETID.WASHINGTON.EDU
}
[domain_realm]
netid.washington.edu = NETID.WASHINGTON.EDU
.netid.washington.edu = NETID.WASHINGTON.EDU
.s.uw.edu = NETID.WASHINGTON.EDU
then,
kinit UWNetID@NETID.WASHINGTON.EDU
will prompt for your password, and klist will display the credentials obtained.
UPPER CASE LETTERS are required.