Blog Home > PortalGuard > You Asked We Delivered…v5.6.2.0

You Asked We Delivered…v5.6.2.0

| 0 comments

PistolStar is committed to keeping PortalGuard up to the standards of the industry and the people who use it. Back in March, we asked our loyal customers what they would like to see upgraded or added to PortalGuard. Straight from our customers feedback we made the following changes. Take a look!

Server License Expiration Email Reminders

PistolStar’s Account Management team starts sending license renewals 90 days prior to license expiration, but these communications typically go to an organization’s Accounts Payable department. This leaves the IT department out of the loop, but if they’re unaware of the notice and the license expires, they are left in scramble mode.

This new feature starts automatically emailing a configurable list of organization contacts when a PortalGuard server license is within 10 days of expiration. These emails are sent no more than once a day and the emails will stop once a license is more than 3 days past expiration. As a redundancy, licensecheck@portalguard.com is also CC-ed on these emails. Each PortalGuard server will send out independent license expiration warnings. *img-1

img-1

CAS SSO Username Manipulation

During CAS-based SSO, a primary user claim is always returned to the application server. The CAS protocol supports optional claims, but most applications that support CAS only utilize this primary <cas:user> value. Since the PortalGuard IdP added support for CAS, this primary claim value has always been the username as entered by the user during their login to PortalGuard. This can cause problems in environments where users can login both with a bare username or an email address.

This new feature allows the following options for manipulating this primary username claim. They are evaluated sequentially in the following order:

1)            The base username value can be:

  • The username as entered by the user (the default behavior),
  • A different field pulled from the user’s LDAP account, or
  • A static/fixed value (the same value is returned for all users!)

2)            The value from the prior step can be made UPPERCASE, lowercase or left as is.

3)            A substring of the resulting value can be returned by searching for a fixed string or returning a fixed number of characters.

Sync Last Password Change via LDAP

One of the benefits of PortalGuard’s Native Windows Authentication feature is that it closely approximate users’ password expiration dates in PortalGuard with what was in Active Directory. PortalGuard now supports this same functionality when utilizing just the LDAP protocol which scales much better than the outdated “NetUser…” API functions upon which the Native Windows feature relies. Please note that the Native Windows Authentication feature will be deprecated in a future PortalGuard release.

When enabled, this new feature will read the user’s “pwdLastSet” Active Directory attribute when the user attempts any actions through PortalGuard and save into its own “LastPWChangeTime” user profile field. This “pwdLastSet” field is automatically updated when a user’s AD password is changed.

This feature is intended to be used in conjunction with PortalGuard’s new “Computed” password expiration method to eliminate all discrepancies between AD’s expiration and PortalGuard’s own. This ensures a consistent user experience related to password expiration regardless of whether the user is logging into their workstation or PortalGuard through a web browser.

“Computed” Password Expiration Method

Since its inception, PortalGuard has had the ability to enforce password expiration. It uses a configurable expiration interval to accommodate organizations’ differing security policies. One problem with the implementation was that the expiration date was computed only when a password was changed. The resulting date was then saved in the “ExpirationDate” field of the PortalGuard user profile and was not updated until the next password change. While saving time and compute resources, this approach had the downside of not honoring subsequent changes to the Expiration Period in the PortalGuard Security Policy. This is not the expected behavior and it necessitated additional maintenance tasks around PortalGuard’s password expiration date.

This version of PortalGuard introduces a new method of determining users’ password expiration that computes it at runtime based on users’ last password change (or reset) time -AND- the current Expiration Period in the PortalGuard Security Policy. This method of computing the next expiration from the last password change time is utilized by Active Directory so it brings PortalGuard more in line with expected behavior. Coupling this feature with the new “Sync Active Directory ‘Last Password Change’ Date” setting in the User Repository described above eliminates all discrepancies between PortalGuard and Active Directory password expiration prompting.

The other critical setting to accomplish this has PortalGuard utilize the msDS-UserPasswordExpiryTimeComputed computed AD attribute. This is a virtual attribute that is computed when requested based on the user’s GPO. It fully supports AD’s “Fine-Grained” password policies and is the last step to ensuring PortalGuard’s prompts regarding password expiration align completely with Active Directory. This setting also fully supports both AD accounts whose passwords never expire and those whose passwords must be changed at the next login. The only caveat is that msDS-UserPasswordExpiryTimeComputed attribute is only available when AD is running at Windows 2008 functional level or higher. The new PortalGuard Security Policy setting also eliminates the need to manually keep PortalGuard’s “Expiration Interval” setting the same as AD’s “Maximum Password Age” GPO setting.

End-User Password Expiration Email Reminder Enhancements

In conjunction with PortalGuard enforcing password expiration during user actions, sending automated email reminders to end-users whose passwords are due to expire soon is also recommended – see the Email Expiration Reminders section. The following enhancements have been made to this feature.

Use AD’s ‘Computed Expiration Time’

Starting in Active Directory’s Windows 2008 functional level, a new attribute named msDS-UserPasswordExpiryTimeComputed became available which can be queried to determine users’ actual password expiration date. If you are using an Active Directory repository as the expiration “Source Directory” and it is at or above this functional level, then you should enable this option. Otherwise, the expiration date will be computed manually using the user’s pwdLastSet time in AD and the expiration interval in the Email Expiration Reminders configuration (which may not be correct for all users).

Include User-Specific Details

By default, the expiration reminder email feature blind-copies multiple users on the same email. Since the email is ‘shared’, user-specific attributes could not appear in the email. The new feature sends a single email to each recipient so the inclusion of user-specific data is now possible.

With this new feature, user-specific attributes like first name & account name will be read from AD at runtime. This option allows new attributes to be included in both the Subject and Body of the expiration reminder emails. The newly available user-specific placeholders/attributes are:

  • {FIRST_NAME} – The user’s first name (“givenName” in AD)
  • {LAST_NAME} – The user’s last name (“sn” in AD)
  • {ACCT_NAME} – The user’s account name (“sAMAccountName” in AD)
  • {CN} – The user’s Common Name (“CN” attribute in AD)
  • {DSP_NAME} – The user’s displayName from AD

Support for HTML Emails/Formatting

By default, emails are sent as text only. You can enable this new feature to better style and format the body of the message. External images and style sheets can be referenced in the HTML markup but be mindful that some email clients may not render HTML as expected.

Log/Audit Kerberos SSO Activity

PortalGuard now tracks and can report on Kerberos SSO activity in your LAN. Both successes and failures are logged in PortalGuard’s RBAEvents SQL table. A new report shows this activity in the Admin Dashboard Activity Reporting. img-2

 img-2

This data is also saved in the PortalGuard Windows Event Log if you are currently exporting its data to a SIEM: img-3

 img-3

 Configurable Identity Provider Metadata

By default, the URLs contained in the PortalGuard IdP metadata echo the protocol, server name and port used to request it. For example, when metadata is requested using http://localhost/sso/metadata.ashx, then all URLs contained within in the generated metadata will start with http://localhost. Similarly, requesting the PG metadata using https://pg.acme.org:444/sso/metadata.ashx will cause all contained PG URLs to start with https://pg.acme.org:444. This behavior can be problematic when PortalGuard is behind proxy servers.

If you wish to have the PG server always use a fixed protocol, server name, and port in its metadata URLs, then that value can now be hard-coded in the General IdP Settings. The default behavior is still to echo the requesting protocol, server, and port.

New Help Desk Options

The following improvements have been made to the Help Desk “Modify User” feature:

  • Expiring a password either as a stand-alone operation -OR- as part of a password reset now also expires the password in Active Directory via LDAP if the “Change Password as Admin?” setting is enabled on the LDAP Advanced tab: *img-4

img-4

Previously, the AD account was only expired from the Help Desk action if PortalGuard’s Native Windows authentication feature was utilized.

  • Under the “Clear Specific PG User Field” action, the following new entries have been added:
    •  Challenge Answers (Mandatory Only)
    • Challenge Answers (Optional Only)

NOTE: The “Challenge Answers (ALL)” entry has been slightly renamed, but it remains and still deletes both types of answers: img-5

img-5

 

To upgrade to PortalGuard 5.6.2.0 email us at techsupport@portalguard.com or give as a call 603.547-1200!

 

 

Please follow and like us:
0
Gregg Browinski

Author: Gregg Browinski

Gregg, PistolStar’s Chief Technology Officer, oversees PistolStar’s product development and technical support. Prior to joining the company in 2001, he received extensive experience as a developer at IBM Lotus and Iris Associates. Gregg has served as the lead architect and developer for PistolStar’s Password Power suite of authentication solutions. He is responsible for the product’s technical success and the recognition it has received through award nominations.

Leave a Reply

Required fields are marked *.


Main menu