active directory

Redmine LDAP Integration – Active Directory Configuration

by Nick 10 years ago

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 youcould 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

by Nick 10 years ago

Your ability to determine last logon time 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 usew32tm /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.