Web Application Needing to Validate Users From Different Domains
A company I had done some work for has a process that they go through for their custom application. This application must authenticate the user so it can do pass-through authentication. Their process grabs the sAMAccountName attribute from the user object. contoso.com\richpec would, of course, have the sAMAccountName of richpec. Then they use the REMOTE_USER parameter through Integrated Windows Authentication and pass that to the web application as contoso.com\richpec. They have a custom policy that then rips off the NetBIOS name of the domain and matches sAMAccountName to the stripped REMOTE_USER and richpec then matches richpec and they are authenticated.
They acquired companies and all of the sudden had more than one domain and needed to find a way to make it work. Thus I was asked to help them find a solution and single sign-on solutions were not in the budget. So here's what I did.
I created a custom attribute within the Schema in Active Directory of my test network. I named the attribute authenticatingUsername. Here are the values I gave it:
Attribute Name = authenticatingUsername
Description = Authenticating-Username
Common Name = Authenticating-Username
X.500 OID = 1.2.840.113556.1.4.555 (more on this in a second)
Syntax = Unicode String
Minimum = 0
Maximum = 256
Attribute is active = Checked
Index this attribute in Active Directory = Checked
Ambiguous Name Resolution = Checked
Replicate this attribute to GC = Checked
About the X.500 OID... In order to create an attribute in the Active Directory Schema a X.500 OID must be defined. The OID (Object Identifier) is used to ensure that no two objects have the same Identification and, therefore, genuine and original throughout the enterprise. The OID for sAMAccount name is 1.2.840.113556.1.4.221. I did a search through my Active Directory Schema for 1.2.840.113556.1.4.anything and found that 1.2.840.113556.1.4.555 didn't exist as an OID. I then searched that OID on the Internet and found absolutely nothing so I figured I could use it for testing purposes.
(Note: In a production environment, DO NOT randomly create your own OID. The OID must be unique and guaranteed that no other schema extension will try to create an object with that ID. Therefore, you must obtain a custom OID from the Internet Assigned Numbers Authority (IANA www.iana.org ) so that you are guaranteed to never have conflicting objects in the Active Directory Schema that other applications needing to extend the Schema are attempting to create with the same OID. Well, guaranteed as long as other 3rd party application development companies follow RFCs and register object classes with IANA. Too often have we seen support cases where customers attempting to extend the schema using ADPREP /Forestprep fail because 3rd party applications wrote schema extensions and when we create our attributes for schema extension, and registered them to be unique, they conflict with objects in Active Directory and the Schema update fails.)
The Internet Assigned Numbers Authority (IANA) assigns private enterprise numbers, which are OIDs, in the arc 1.3.6.1.4.1. IANA will assign a number (NEWNUM) so that the new OID arc will be 1.3.6.1.4.1.NEWNUM. These numbers can be obtained from the IANA Web site (www.iana.org).
More information about Object Identifiers can be found here:
https://en.wikipedia.org/wiki/Object_identifier
I then reloaded the Schema and went into the classes container of the Schema and modified the properties of the user class. I added authenticatingUsername as an attribute of the user class. This is done to enable the ability for a user object to be populated with an attribute called authenticatingUsername. I reloaded the Schema again.
Now I needed to populate all user accounts with their respective authenticatingUsername attribute. I used ADModify.net and did a modification of a custom attribute to all user accounts. There is a tab for Custom where you can define the name of the custom attribute to change and what value to give it. I told it to change authenticatingUsername and give it a value of myfirstdomain\'%sAMAccountName%' and then did it to the second domain also as myseconddomain\'%sAMAccountName%' and so on and so forth.
Then, the process was to change the query to grab the authenticatingUsername attribute instead of sAMAccountName.