Skip to main content

Guest Accounts

PEM Administrator integrates with your Active Directory (AD) for identity and access management. All PK Protect user credentials come from AD. The security groups a user belongs to can also dictate what PK Protect policies or rules apply. When an administrator creates a user account, PK Protect will look for the user in a few different places.

AD User Email Address

Active Directory User General Tab

First, PK Protect will look for an email address defined for their AD User Object. PK Protect will then create an identity for that AD user, using the AD password to authenticate the account on the client. In the above screenshot, the account would be created with the address.

User Principal Name

Active Directory user account tab

If an email address for the new PK Protect user is not in AD, PK Protect will fallback to using the User Principal Name (UPN) defined for the user account. This creates what looks like an email address by combining the user logon name and the domain suffix for the domain the user belongs to. In the above screenshot, the account would be created with the pseudo-address dev@PK, even though it is not an email address. It becomes the way to address the dev PK Protect User. Users connected to PEM Administrator through UPN must belong to an Authorized Domain to have the same privileges as an AD user.

Authorized Domains

Across your PK Protect Ecosystem you might have any combination of user accounts with UPN or Emails being used. 

When PEM Administrator is set up and authenticated, the PK Protect Cloud delivers a list of Authorized Domains to PEM Administrator. If a user's email address comes from an authorized domain, the account is confirmed for external sharing. This means that a user belonging to an authorized domain on a PEM Administrator can create and use Smartkeys to share data with people outside the organization.

Guest Accounts

If a PK Protect administrator creates a user with an email address that can't be authenticated through the organization's Active Directory, and is NOT in a PK Protect authorized domain, a Guest account will be created. Guest users cannot share encryption keys with the outside world.

The following example illustrates the differences between user accounts.

Guest Account Example Scenario

PEM Administrator Authorized Domains List:,

User 1:

Email: Unavailable/not in AD


User 2:



User 3:


UPN: keys@qa.local

Account Status

IdentifierIdentity MapperStatus
User 1UPNAuthorized Account - The UPN has which is an authorized domain for the PEM Administrator
User 2EmailGuest Account - The Email address is defined and does not match one of the authorized domains for the PEM Administrator
User 3EmailAuthorized Account - The Email address includes, which is an authorized domain for the PEM Administrator, even though the UPN is not in the authorized list

Authorized Account vs. Guest Account

There are some differences between the types of accounts. In general, there are configuration options that can be used to narrow the gap to provide a similar user experience for Guest accounts.

Both AccountsAuthorized AccountGuest Account
  • Credentials managed and controlled through Active Directory
  • Access for Smartkeys managed and controlled through Active Directory Security Group membership
  • Support for Integrated Windows Authentication (IWA) for a "no login" experience

  • Automatic Server Detection on Mobile
  • Sharing Smartkeys external to the PEM Administrator
  • Requires Manual Entry of PEM Administrator URL
  • Windows Registry settings can be defined for users.
JavaScript errors detected

Please note, these errors can depend on your browser setup.

If this problem persists, please contact our support.