News & comment tagged ‘active directory’
● Active Directory for the AR System administrator
posted by Danny Kellett on 18th January 2011
OK, so you'ave been a workflow guru for a while now. You have read a few ars-list posts about integration with Active Directory or LDAP, you maybe have looked at the ‘OU=’ queries and thought “...yes... hmmmm” but left it at that and decide the detail is for another day.
Then, without warning, you're told: “We need our users in Remedy/AR System/ITSM to sync with AD”, or asked “Why are our usernames different to our domain names?”
Now us AR System administrators are made of some tough stuff. We know it can be done, we have seen posts on lists so we know we don't have to reinvent the wheel and more importantly, we don't want to become AD/LDAP administrators or design corporate networks, we don't want to read the overly detailed Microsoft Technet bibles that are the size of small car, with font sizes of 1 and are known to trigger narcolepsy before the first chapter.
We just want to know enough to get the job done, save a bit of time automating something and of course ticking off another item on the new years resolution list, “Learn some new techie stuff”.
For many things in life, you have to start at the beginning before you can move on to the rest. That start is here. My first, in what I will hope is a series, will be an introduction into AD, the basic terminology and how to query it.
What is Active Directory
If you visit the Microsoft website seeking a definition of AD, you will find words such as hierarchical, distributed, extensible. Then you stumble across terms such as trees, forests and leaves. See what I mean? Confusion from the first step. As promised, I will keep things simple and on a need to know basis. Depending on the version of Windows Server you are using, will depend on what term your AD will be known as. Here are a few: Active Directory Domain Services, Active Directory Lightweight Directory Services, ADAM... The important thing to know, is that all of the above can be explained as a datastore of information. This data is organised into individual objects, each object having certain set of attributes associated with it. For example, in AR System terms, we have an AR System schema, with forms and those forms have fields.
Now I think that's enough boring explanation for the first entry. So now lets see what your domain says about you. If you are using a desktop/laptop that's joined to a domain, you can query using a built in console. If not, but you have network access to a domain, then you can use a Microsoft utility called ldp.exe.
Click the Start button -> Run (or if this has been hidden by your administrators then you can run this command through a cmd.exe or command prompt):
%SystemRoot%\SYSTEM32\rundll32.exe dsquery,OpenQueryWindow
Make sure there are no spaces before or after the comma.
If you see an error message "The Active Directory Domain Service is currently unavailable" then you are not logged into a domain and you will need to use the ldp.exe with a domain login name and password (Will show you that in the next blog).
So now you have the dialog. Put your domain name in the Name field and click Find Now. You should see the results pane with your domain entry. From there you can right click and view the properties etc. There is an Advanced tab where you can specify more search attributes etc. Have a play!
The next blog entry will show you how to query for more interesting data such as new accounts from a specific date, find people with or without an email, find accounts that are disabled etc.
Thanks for your time.
Danny
● The pre-requisite step for Integrated Windows Authentication
posted by John B on 16th January 2011
What's Integrated Windows Authentication?
Integrated Windows Authentication is the process where by you open Internet Explorer, navigate to the BMC Midtier homepage, and sign in as the current Windows user without using the login screen.
In order to provide a full IWA implementation without the use of a Microsoft IIS front end, you require built-in Active Directory authentication.
The JSS SSO Plugin is the only SSO product in the BMC market to fully implement IWA.
The two protocols within IWA
There are two elements within IWA: Kerberos and NTLM version 2.
Prior to version 3.1 of SSO Plugin, we provided a (modified for security purposes) implementation of NTLM version 1, however with Windows 2008 (which doesn't allow NTLMv1) becoming more popular, we could no longer rely on NTLMv1 and therefore implemented NTLMv2.
In version 3.1+ of the product, the IWA implementation provides both Kerberos and NTLMv2.
The pre-requisite for built-in AD
NTLMv1 requires a user account in the Active Directory to authenticate clients, but NTLMv2 requires a Computer account. We provide a script called set-serivce-account.cmd to set up the AD entry, and also add the Kerberos Service Principal Name (required for Kerberos to work correctly).
Part of the reason we provide a script is the Active Directory Users and Computers tool allows a Computer account to be added, but does not allow the password to be set! So our script adds the Computer, sets the password, and also configures the Kerberos SPN.
If your AD team do not want to run our script, we provide a detailed set of manual steps in the installation guide, and we're happy to discuss the requirement with your AD team if that would be helpful.
If you want to look at the script running, view this video and scroll through to 2 minutes.
Simplified SSO Plugin configuration
In SSO Plugin 3.2, we simplified the configuration of IWA by providing just four fields in a configuration called ‘built-in AD’.
We also provide an an advanced set of controls that provide all the configuration options for Kerberos and NTLMv2 in an integration called ‘built-in Kerberos/NTLM custom settings’.
IWA without NTLMv2
It is possible to configure the SSO Plugin with only Kerberos, but this doesn't provide the full IWA implementation. Your Windows network administrators will need to ensure the network is configured to run Kerberos reliably without browsers falling back to NTLMv2, as is common and why Microsoft IIS accepts both Kerberos and NTLMv2.
We recommend you configure both Kerberos and NTLMv2.
● What's a Service Principal Name (SPN)?
posted by John B on 2nd January 2011
The SSO Plugin supports Integrated Windows Authentication, so users can open IE and sign directly into the BMC Midtier without logging in. There are two ways in which this can be achieved: Using IIS or by directly integrating with the Active Directory. Both methods require a Service Principal Name (SPN) to be correctly configured to allow a browser to use the Kerberos protocol (IWA requires two protocols, Kerberos and NTLMv2, and this is discussed in another article).
To instruct a browser to perform SSO against the Midtier, an SPN must be assigned to an account in LDAP/Active Directory to associate a Service (such as a web site, ie the Midtier) with a Principal (an account) that is authorised to authenticate users of that Service.
So for site 'http://site.example.com/', the Principal name 'HTTP/site.example.com' is used. The client browser looks up objects in Active Directory that have this name set as an SPN, and uses data from those objects as part of the signing process to generate the ticket sent to the web server. Without an SPN set for a given site, the browser cannot send Kerberos authentication tokens. Adding an SPN has no security impact because the authenticating service doesn't get to see any sensitive information about the user. However the account with the SPN must match the account that the authenticating service is operating under - typically, in Active Directory, the Computer object of the machine running IIS.
If a site is accessible under multiple names, eg 'site.example.com' and just 'site', then multiple SPNs must be set on the same account, one for each Principal name under which the site will be accessed.
Typically, an IIS instance will already have an SPN configured, but when you are integrating SSO Plugin with the AD using the "built-in AD" integration type, an SPN needs to be created and associated with the required Computer Account in the AD. We provide a script to automate this process for you, and manual instructions are provided in the documentation.