Blog Home > PortalGuard > Top 3 Problems seen in a Tech Support Role

Top 3 Problems seen in a Tech Support Role

| 0 comments

 PortalGuard Tech Support

Here at PortalGuard Technical Support, we get quite an assortment of inquiries needing resolution/understanding by our customers and prospects. We are committed to taking the time to document or build into our product what is needed to eliminate these questions from taking up too much time for us and our customers. However, I have been able to find three concerns that I see the most in tech support.

Top 3 Problems seen in a Tech Support Role

1.Password Expiration Synchronization between PortalGuard and Active Directory

PROBLEM: Your company is particularly keen on making sure employees consistently change their passwords in an effort to limit any unwanted entry into your valuable system. Your company has also put PortalGuard in place as the secure login to your sensitive web resources.  This means that PortalGuard and Active Directory will need to have the same expiration date for the user’s ever-changing password.  When the password expiration is out of sync, a user may be blocked entry through PortalGuard because PortalGuard thinks the password is expired even though they had just changed it in AD through Windows password change utility.

SOLUTION: If you have not yet upgraded to the latest release of PortalGuard, 5.6.2, the following steps will allow you to circumvent this issue in your current environment.

Enabling password synchronization between AD and PG can be done by checking the “AD Password Expiration Sync” check box on the Native Windows tab of your user repository (as shown below).

Top 3 Problems seen in a Tech Support Role

However, there is more information that you will want to be aware of to make the most efficient use of this PortalGuard feature.

If users have never logged in through PG, then PG won’t have any expiration data for the user.  It’s the login through PG that triggers PG to set the password expiration date in the user’s PG profile.  PG does have a Batch Import utility that can be used to “enroll” users before they actually login themselves. User profiles are created during the Batch Import so PG will also calculate and save the Expiration Date for the user at that time.

For user’s that already exist in PG but need to be “automatically” synched with AD, the PG Batch Import Utility can be used to establish password expiration synching.

The steps include:

  1. Create a .csv file with all the users to enroll
  2. Run the .csv file through the PG Batch Importer

The following actions will help you satisfy step 1.

Below is an AD PowerShell script that will dump out all users in AD with the following information:

1)      sAMAccountName

2)      Last logon timestamp

3)      Last password change timestamp

4)      If the password is set to never expire for the account

It will stream this into a file named “AD_user_expiry.csv” in the current working directory.

Here’s the script:

Get-ADUser -filter * -properties samaccountname, lastlogondate, passwordlastset, passwordneverexpires | sort-object samaccountname | select-object samaccountname, lastlogondate, passwordlastset, passwordneverexpires | Export-csv -path AD_user_expiry.csv

Be sure to launch the AD Module for PowerShell otherwise the “Get-ADUser” cmdlet won’t be recognized:

Top 3 Problems seen in a Tech Support Role

The final CSV file that will be imported into PortalGuard only needs the username and “final”/computed expiration date which can be achieved by simply adding your AD password expiration interval (e.g. 90) to the “passwordlastset” column values. Besides using column headers of “Username,ExpirationDate”, the date value must be formatted as YYYY/MM/DD for PG to accept it.

The PG Batch Importer will help you satisfy step 2.

If you are not familiar with the PG Batch Import Utility, our Admin User’s Guide has detailed instructions starting on page 48.

Additional important knowledge/suggestions for the PG Password Expiration Synch with AD feature:

  • For the PG password expiration date to always be up to date and accurate, you will need to continually run the Get-ADUser command to create the CSV, manipulate/scrub the CSV, then batch import it.
  • The PG ExpirationDate field can get set in the following ways:
    1. When the user attempts to login through the PG website (requires the Native Windows –> Sync Active Directory Password Expiration setting to be enabled)
    2. When the PG user profile is first created.  This could be via batch importer or a login to the PG website.  The expiration interval in the PG Security Policy minus any defined grace period is used as the initial ExpirationDate.  This could be immediately overwritten by the current batch importer run if it defines the ExpirationDate column as described in #1 above.
    3. When the user updates their password through the PortalGuard website.
    4. When the AD password is changed via Ctrl-Alt-Del on the Windows workstation and the PG Desktop client is installed.

Miscellaneous Helpful Points:

  • As an additional data point, you can use this VBScript utility to compute and display the AD expiration time for a specific user (it only uses AD data):

http://www.pistolstar.us/_download/VBS_PWExpiration.zip

  • Lastly, here is the SQL command to report on PG’s own password expiration dates – it will sort the results by username:
select uname, CONVERT (varchar(10), XMLData.value(‘(//ExpirationDate/text())[1]’, ‘varchar(30)’), 111) as PWExpiration from userprofile order by uname

2. Enable SSL over LDAP for PortalGuard Access to AD

 PROBLEM:  You want PortalGuard to provide self-service password reset (SSPR) for the users on an Active Directory (AD) Domain Controller (DC).  PortalGuard requires a secure connection to AD to protect the new password as it travels over the wire.  For whatever reason, you aren’t able to use the Native Windows API for secure password resets and want to use the LDAPS option.

SOLUTION: Configure the AD DC with a Digital Certificate and export it to the PG server.  The Digital Certificate can be purchased from a well-known Trusted Certificate Authority or you can create your own self-signed certificate.

Whether you have a self-signed cert or a well trusted one, the next two steps are:

  1. Import the PFX file into the personal cert store on the AD server for local computer
  2. Import the CER file into the Trusted Root Certification Authorities for both local computer and current user on the PG Server

3.Change SSO Landing page to be the default PortalGuard page

PROBLEM:  By default, navigating to the root of your PortalGuard server delivers you to the PG Account Management Page, but you prefer to have your users brought to the PG SSO Landing Page.

SOLUTION: To prevent access to the Account Management page and redirect users to your PG SSO Landing page, make the following changes:

  • In the C:\inetPub\PortalGuard folder of the PG server, rename “default.aspx” to “default.acctmgmt” – this will ensure IIS can’t serve it up as an ASPX page
  • Create a new default.aspx with the following contents and put it in the same folder from step 1)

default.aspx contents:
<%@ Page Language=”C#” Inherits=”System.Web.UI.Page” %>
<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Strict//EN” “http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd”>
<script runat=”server”>
string m_RedirectURL = “https://<YOUR.PG.SERVER/sso”;
void Page_Load(Object Src, EventArgs E) {
Response.Redirect(m_RedirectURL, true);
return;
}
</script>
<body>
Redirecting…
</body>
</html>
• Replace

  • Replace the <YOUR.PG.SERVER> with the hostname for your PG server.
  • Save the change
  • Try it out!

PortalGuard prides itself on not only providing you with a first-class product, but it comes with excellent tech support based in the United States. If you have any technical questions or concerns, you can talk to a PortalGuard Tech Support engineer who works with the product on a daily a basis.

To learn more about how PortalGuard stays current with new technologies and trends, please visit our website www.portalguard.com or give us a call 603.547.1200.

Please follow and like us:
0
Larry Conroy

Author: Larry Conroy

Larry is a Technical Support/Developer here at PistolStar. With a Master’s Degree in Computer Science, he has worked for Raytheon, and then moved on to other corporations, such as Kronos, Axent, and Applied Microsystems. Over the last ten years Larry has specialized in improving and growing the support process, previously and within PistolStar Inc.

Leave a Reply

Required fields are marked *.


Main menu