Redmine LDAP Integration - Active Directory Configuration

After you have Redmine installed and configured to the point where you can log in - go ahead and do so. Browse to Administration>Settings>Authentication tab>LDAP Configuration (in the bottom right).

Before you go and start changing things here, there are a few things you should keep in mind that will save you some time. Realize that you can't do an anonymous bind to Active Directory. So, you need to actually specify a valid set of credentials for the service account. Now, I suppose they could have done something different here to reduce the configuration work... like relying on user login credentials and passing them to query AD. But in any event, you just need a normal domain user account should do just fine - anything that can query Active Directory. Why a domain account? Think about it another way... if someone plugged their laptop into your network, would they be able to query AD for user or computer objects? No... they wouldn't, because they'd be anonymous. Even if they knew your domain name, had a domain controller's IP address, the distinguished name, etc... no luck. So create a service account. Just FYI, my domain was at 2003 domain functional level.

As far as the Base DN - keep it simple... base DN means base. You probably don't want CN=users, or CN=MyBusiness, or anything like that. In my case, I specified DC=domain,DC=local. As for the the attributes, they all come right out of Active Directory... there's a bunch of places you could find these if you wanted to spend the time to find them. Or, there's a bunch of sites that already have this stuff listed (see the below for my config).

When you're specifying the attributes, keep in mind that you don't want any extra spaces (blank spaces) after the attributes. For instance, it should be 'SAMAccountName' (no quotes), NOT 'SAMAccountName '. If you add a space, it breaks. If you don't have those "optional" attributes, it breaks. Also - just FYI... if you're under Authentication, and trying to run a "Test" of authentication, and it say's successful - that doesn't mean it's actually working. You need to test Active Directory account logins from back on the main menu.

If you want to use on-the-fly account creation... you'll need to make sure all of your Attributes are set correctly and that within Active Directory the attribute fields actually contain data for your users. This is very important. For example, if you have a user trying to login, but their account has "First Name", and/or "Last Name", and/or "E-mail" address fields blank (like if you have a "test" user account) - automatic user account creation in Redmine will fail. On top of that - it's not very verbose about why it failed. So that might be something to file away in the back of your mind, so that when you find one account (or a group of accounts) somewhere that won't login - you can make sure to check that they have all of the Active Directory attributes specified (just open up Active Directory Users and Computers and check-out the user object that is having a problem).

My Settings:

• Name: YourDomainOrWhateverYouWant
• Host: IP address of a Domain Controller (name is probably best)
• Port: 389
• Account: Domain\ServiceAccountRedmine01
• Password: SavedPassword
• Base DN: DC=domain,DC=local
• Login: SAMAccountName
• First Name: givenName
• Last Name: SN
• Email: mail

AD: How to Determine the Last Logon time of users

I don't think there's a really good short answer to this one, as your ability to determine last logon times really depends on the AD level that you're at.

For information on the below attributes (and more), check here.

Pre-2003 AD: You can't do it.
2003 AD: Look at the lastlogon attribute on all DCs.
2003 AD functional level: Look at the last-logon-timestamp
2008: Check the msDS-LastSuccessfulInteractiveLogonTime

If you're not at 2008, or 2003 domain functional level, and you want to determine the last logon time, you can use AD-FIND to query each DC, get the time stamp in the nt time epoch format (the time measured in seconds since 1/1/1601) and then use w32tm /ntte to convert the stamp into a readable format... Date, Hour:min:second.

adfind -h DC1:389 -b dc=domain, dc=local -f "objectcategory=person" lastlogon >DC1.txt

adfind -h DC2:389 -b dc=domain, dc=local -f "objectcategory=person" lastlogon >DC2.txt

... and so on for each DC.

To convert lastlogon time, take the time stamps for the user's that you're interested in and convert them...

w32tm /ntte value1
w32tm /ntte value2

... and so on.

Then you can compare each. At 2003 functional level the attribute lastlogontimestamp is replicated to each DC - so it's a single source of truth. In 2008 it gets even better with last logons, last failed logons, and more. With some diligence, you can probably take the above steps do some further learning around them to improve things a bit, and then script the the logic. But for one-offs, and small networks this works.

DekiWiki - Active Directory Integration

As far as Active Directory integration with Dekiwiki goes, it's actually not too difficult to setup.

First, they've got some setup instructions here, plus they have active forums.

The only problem I ran into with the instructions was with the searchbase syntax in the configuration. The instructions make it appear that you should specify the hostname twice… once in the hostname configuration, and then again as part of the Distinguished Name (DN) that you’re providing for searchbase. For instance, I was specifying “dc=DCServerName, DC=domain, DC=local. On the client side (the web interface), authentication attempts were failing, but while watching DCServerName’s security log, it showed successful authentication attempts coming from the Dekiwiki box.

To resolve this, all I did was remove the dc=DCServerName from the searchbase. Once I removed it, such that the searchbase configuration was dc=domain, dc=local –it worked.
As an aside, all of this was done in a standard SBS 2003 R2 environment. Nothing extra or special required on the SBS server.

AD-COIT v2.52 Released - Adds CSV output and more inventory options

I posted an update today to my AD-COIT script over on SourceForge.

With the latest release, version 2.52 adds CSV output and local admin group enumeration. CSV output, together with improving readability, makes it easier to manipulate your data using a spreadsheet app. You may notice a few bugs in the output, but all-in-all I think it was worth the time to update the release.

The most recent changes were driven by internal needs – as well as your emails and comments – so keep them coming! Mainly we needed to find and fix local admin groups, as well as just make it easier to work with our data.

As always, your input is encouraged. Let me know if you have anything you’d like to see added!

AD-COIT v2.52, Inventory Tool Released on Sourceforge

Last updated: 5/14/2007

AD-COIT (Active Directory – Computer Object Inventory Tool) is a script that I’ve put together to automate the hardware/software information gathering and inventory process, with a focus on simplicity and portability. While the target audience for AD-COIT is small-to-midsized Active Directory environments – specifically for the SBS community - you can leverage it in much larger environments for information gathering and asset tracking. The highlights of what gets logged include: workstation hardware information, operating system and configuration information, installed software, enumeration of local admin groups, and more (see below).

Useful Links:

• Download it now from Sourceforge.net.
• View the sample output (go here for screenshots)
• Usage Information and How-To article
• Frequently Asked Questions (FAQ)
• Look at the source (older post)
  

When you go to run the script ("cscript scriptname.vbs"), the output is both echoed to the screen and written to the .CSV file. During the previous release (2.3), I had a few people ask how to tell if the script was working. Basically, if you see text being written to your command-prompt window, and you’ve configured a valid path for the CSV output (c:\scripts by default), then just let it run. You can always open a read-only copy of the output while it’s working. When it’s finished, use Excel (or something similar) to view/sort the output.

What if I need something specific, will you customize the script for me?
Sure thing. For instance, if you want the results output to a spreadsheet (as of 2.52), or have a different antivirus package you want to check – or… whatever the case may be, just let me know and we can discuss your objectives, and hopefully work out a solution.

Does it do “X”, “Y”, and/or “Z”?
Maybe… if it doesn’t yet, send me an email or post a comment and I’ll consider adding the functionality in a future release.

Does it output to .CSV?
Yes… as of v2.52. Thanks to everyone who emailed me with this suggestion! If you havn't updated recently, go grab the latest copy!

What gets included in the inventory?
The full list includes: Individual system information organized by computer name, including… operating system, service pack level, installation date, manufacturer name, BIOS name, service tag, processor information, domain role, current user, model, RAM, daylight savings status, time zone, Symantec Antivirus definition date, free space on the local drives, list of installed applications, enumeration of the local admin group, as well as a summary of the FSMO-role holders, non-responsive systems, and systems which logged errors.

Why did you write the script?
It started out to help me troubleshoot some daylight savings time problems for a new client, and then just evolved from there… adding functionality where appropriate.

Did you know something - fill-in-the-blank - doesn’t work right?
I probably am not aware of it. If you find something doesn’t work the way you expect, or is simply broken, please let me know, and I’ll take a look (yes, I do know that FSMO roles aren't written to the CSV file).

DNS: Troubleshooting name resolution issues

I had an interesting conversation about name resolution with a consultant who was on-site with a customer. He was having problems finding a machine by hostname… the conversation was interesting from the standpoint that name resolution is something most people take for granted, and I thought it was worth posting because the situation was a bit non-standard, and useful for discussion.

“I added a machine to the network, and I can ping it by IP address because I know the address, but when I ping by name, I get “request timed out”, and the IP that it responds with is the wrong address.”

Okay, so is this a Windows 2000/2003 AD environment, using AD-integrated DNS, and WINS?

“Yes, AD-integrated DNS, WINS, etc”.

Does the workstation have a static IP?

“Yes, it has an IP of xxx.xxx.xxx.xxx and it’s pointed at the internal DNS server.”

Is the machine that you’re having problems with a member of the domain?

“No. See, the machine needs to be in a workgroup because… [some valid reason].”

How are you doing name resolution?

“Well, I have the client pointing to DNS, so DNS should resolve it.”

Have you checked the DNS management console? Because it might not be registering; or it's registered with the wrong IP.

"You’re right. Why isn’t it registering?"

Since it’s not a member of the domain, you need to allow “Nonsecure and secure Dynamic updates” in DNS (DNS>Server>Forward Lookup Zones>corp.domain.com). Then, you need to specify a DNS suffix for the connection on the client, tell it to register, and have it use the connection’s DNS suffix in DNS registration.

"Okay, done. But I’m still getting that wrong address when I try to ping it by name."

Did the machine come up and grab an address from DHCP before you gave it a static IP?

"Yes."

It probably registered in WINS; open up the WINS management console and delete those entries that are no longer relevant for the client… either that, or point the client to the WINS server.

"It worked!"

To summarize, when the client came up for the first time and pulled an address via DHCP it registered with DNS and WINS. After assigning a static IP to the client, he was able to ping it by IP. But when pinging by hostname, the host was resolving the old IP that had previously been registered in DNS and WINS. By the time I got involved he had unregistered the client from DNS, but not removed the entries from WINS. I had him turn on unsecured dynamic updates to DNS, set the DNS suffix on the client, and the machine started registering properly.

It’s important to keep in mind that unsecured dynamic updates to DNS can be a security risk. The default behavior in Active Directory-integrated DNS is to only allow secure updates, so this should be considered before making such changes.

WMI: Scripting DSQUERY to report FSMO roles

This script executes a series of "dsquery" commands to determine which servers house the FSMO roles on your network. This will later be incorporated as a function into my inventory script.

Dim objShell
Set objShell = CreateObject("WScript.Shell")

strCmdRun = "cmd /c"
strQuery = "dsquery server -hasfsmo "
strQuerySchema = "schema"
strQueryRID = "rid"
strQueryName = "name"
strQueryInfr = "infr"
strQueryPDC = "PDC"

Set objExec = objShell.Exec(strCmdRun & strQuery & strQuerySchema)
strExecResultsSchema = LCase(objExec.StdOut.ReadAll)

Set objExec = objShell.Exec(strCmdRun & strQuery & strQueryRID)
strExecResultsRID = LCase(objExec.StdOut.ReadAll)

Set objExec = objShell.Exec(strCmdRun & strQuery & strQueryName)
strExecResultsName = LCase(objExec.StdOut.ReadAll)

Set objExec = objShell.Exec(strCmdRun & strQuery & strQueryInfr)
strExecResultsInfr = LCase(objExec.StdOut.ReadAll)

Set objExec = objShell.Exec(strCmdRun & strQuery & strQueryPDC)
strExecResultsInfr = LCase(objExec.StdOut.ReadAll)

Wscript.Echo "FSMO Roles: "
Wscript.Echo "-----------"
Wscript.Echo "Schema Master: " & strExecResultsSchema
Wscript.Echo " "
Wscript.Echo "RID Master: " & strExecResultsRID
Wscript.Echo " "
Wscript.Echo "Domain Naming Master: " & strExecResultsName
Wscript.Echo " "
Wscript.Echo "Infrastructure Role: " & strExecResultsInfr
Wscript.Echo " "
Wscript.Echo "PDC Emulator: " & strExecResultsInfr


KB: Introduction to Windows Time

"Explain time synchronization on a Windows Server 2003 network."

Time synchronization is an essential component to Kerberos authentication, and by extension Active Directory authentication. The Windows Time Service (W32Time) is responsible for ensuring that all Windows 2000 or later computers share a common time. W32Time runs on UDP port 123.

Time synchronization occurs based on domain hierarchy, such that all desktop computers and member servers nominate their authenticating DC as their in-bound partner. All DCs in turn rely on the PDC operations master, which in turn follows the hierarchy of domains, with the PDC operations master at the root of the forest being authoritative for the organization. Either the system clock, or a specified external source (such as a GPS receiver, or an internet-based time source) can provide a highly accurate seed for the authoritative time source.

The Windows Time Service relies on the NTP protocol to arbitrate time synchronization between partners. NTP packets contain time stamps that include a time sample from both the client and the server involved in synchronization. NTP protocol algorithms then determine and elect the best time sample, and adjust the system clock.

The Windows Time Service relies on standard domain security features. When a computer requests the time from a DC, W32Time requires that the time be authenticated with the session key from the netlogon service. If the packet is not signed correctly, the time is rejected and the authentication failure logged to the event viewer.

In general, XP and 2003 clients automatically obtain accurate time from their authenticating DCs in the same domain.

Click here for a more comprehensive technical reference.