Active Directory Login failure on Blackberry Administration Server (BAS) – The username, password, or domain is not correct. Please correct the entry.

Posted on July 24, 2012

Logging into BAS can fail if DNS records are incorrect or stale.
Before we get into that, I highly recommend you look through your BAS logs to analyse the error.

1) Try to login to the BAS admin service using your LDAP/Active-Directory credentials several times. This will register a few errors in your logs that you can track down.
2) Head to: C:\Program Files (x86)\Research In Motion\BlackBerry Enterprise Server\Logs\(TODAYS DATE)\
3) Open the log file that starts with "SERVERNAME_BBAS-AS-" (Make sure it's the most recently modified version!)
4) Scroll to the bottom and look for lines that start with "(XX/XX XX:XX:XX:XXX):{http-"

(XX/XX XX:XX:XX:XXX):{http-URL.COM%2F10.100.1.36-3443-5} [com.rim.bes.basplugin.activedirectory.LDAPSearch] [INFO] [ADAU-1001] {u=SystemUser, t=30847} performPagedLDAPSearch problem performing LDAP operation: url=ldap://ldapserver.domain.com:3268 base= filter=(&(objectClass=user)(objectCategory=person)(|(sAMAccountName=besadmin)(userPrincipalName=besadmin))) scope=2

If you see a message similar to this, BAS is trying to grab a Kerberos ticket and your DNS is causing errors.

Resolution:

1) Load your Active-Directory DNS management console.
2) Verify that you have reverse DNS setup for the entire domain. You require PTR records (reverse dns records) for each of your domain controllers. If you don't have them, FIX THIS!
3) Verify that you have no stale records pointed to decommissioned or retired domain controllers. Drill down into each DNS folder and confirm the hostname and IP match your current infrastructure. It's amazing how many stale records we find.
4) Once repairs are made to the DNS settings, right click the server name in the DNS management and "clear cache"

Reboot your BES server just for fun, and try to login.

Disable French characters from showing up while typing

Posted on July 23, 2012

One technical support request that I have run into multiple times relates to French characters showing up while typing an email, writing a document, etc. A few examples of these characters are: à, é, and ù.

This behavior is usually due to the Canadian Multilingual and Canadian French keyboards enabled in the Keyboards section of the Region and Language settings of the computer.

To disable the French and Multilingual keyboards, you need to:

1) Open Control Panel

2) Click on Region and Language, or Clock, Language, and Region depending on your Control Panel view:

 

3) Select the Keyboards and Languages tab:

 

4) Click the Change Keyboards button

 

5) Click on Canadian French, then click Remove:

 

6) Click on Canadian Multilingual Standard, then click Remove:

7) Click Apply

8) Click OK

HP System Management HomePage – Processor none – No Hardware Listed

Posted on July 15, 2012

If you recently installed the HP System Management Homepage on a new or existing HP server and you're missing the actual content when you login, you could be missing a quick community setting on your SNMP Service.

1) Goto start -> run/search -> Services.smc
2) Scroll down the list and find "SNMP Service" -> Right Click -> Properties -> Security Tab
3)  Under "Accepted Community Names" look for a "Public" community name. If it's missing, you need to add it. Click "add". Choose "ReadOnly" and enter community name "public".
4) Click Add and then OK to close the windows.

You should now have this:

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

5) Right click the "SNMP Service" and choose "Restart". This will require it's HP dependencies to restart as well, click ok and let it finish

Log back into the HSM Homepage and you should now see everything:

Fortinet SSL VPN Authentication with LDAP – no_matching_policy

Posted on July 12, 2012

We identified a new bug with the Fortinet authentication mechanism being used to query LDAP. If you are using active-directory to authenticate remote SSL-VPN users with no success, please check your event log for a "no_matching_policy" error. Recent escalations with Fortinet have confirmed the username and password being used for LDAP queries must not include complex characters.

Our testing confirms that using characters like "#", "!", and "$" in the password can create the "no_matching_policy" issue. After removing them and sticking to alpha-numeric only, the authentication immediately works. This bug is not applicable to the incoming SSL-VPN credentials; it ONLY affects the account used to query LDAP.

Things to know about the LDAP Server settings:

 

1) Common Name Identifier

Using the "sAMAccountName" as shown above will authenticate your users with their assigned active-directory username. This is case-sensitive.

 

 

 

 

 

 

 

 

2) Distinguished Name

This is the LDAP path to your highest level query folder. You can increase security by drilling down into a specific Organizational Unit (OU), if you prefer. The authentication mechanism will only allow users within or below this path/folder/OU.

Example: DC=domain,DC=CA (this would search the full domain)
Example: OU=users,DC=domain,DC=ca (this would search objects within the users OU only)

3)  User DN (Distinguished Name)

The Fortinet appliance needs a valid and working active-directory user to run queries. This account is used to test incoming SSL-VPN login credentials against your domain controller. You MUST use the complete LDAP path  to this user object. Failure to include everything, even the spacing, will break things. I suggest you look into DSQUERY or ADSIEDIT.MSC for copy/paste of the path.

Example:  CN=LDAPUser,OU=Users,DC=domain,DC=ca

4) Password (for your User DN)

The password field on this page is reserved for the User DN (the user object you will use to send LDAP queries to your domain controller). To avoid the bug described at top of this article, use ALPHA-NUMERIC CHARACTERS ONLY! If you use "!", "#", "$", etc. you may run into failure. I also suggest you do not make your password exceptionally long. Watch your event log for the "NO_MATCHING_POLICY" issue and tweak accordingly.

 

Testing SSL-VPN Authentication from the CLI 

Fortinet has a nice built-in diag you can run to test things. Pick a user with SSL-VPN access and run the following command:

diag test authserver ldap "server-name" aduser "some.user" "password"