Share via

RDS licensing token silent recreation without ADFS

Anonymous
2015-12-19T03:28:03+00:00

Our RDS installations of O365 use “Shared Computer Activation”. This means that most users regularly have to reactivate O365 each time they logon, requiring 3 username/password logons!

According to the “How shared computer activation works for Office 365 ProPlus” section, from “Overview of shared computer activation for Office 365 ProPlus”:https://technet.microsoft.com/en-us/library/dn782860

If your environment is configured to synchronize Office 365 and network user accounts, then the user probably won’t see any prompts. Office 365 ProPlus should automatically be able to get the necessary information about the user’s account in Office 365. It goes on to say: If the user is licensed for Office 365 ProPlus, a licensing token is stored on the computer in the user's profile folder, and Office 365 ProPlus is activated. The user can now use Office 365 ProPlus.

When SCA is used, the licensing token is stored in:

C:\Users<username>\AppData\Local\Microsoft\Office\16.0\Licensing  or  %localappdata%\Microsoft\Office\16.0\Licensing

For our RDS this is the latter.

In the Licensing folder, are 2 files including {XXX…}.authString

Having logged onto the rds on 16th Dec, I was required to Activate Office 365, I viewed this file in a text editor. Here you can find the start and end date of the token e.g.:

2015-12-16T10:32:05.7780000Z_

2015-12-24T10:32:05.7780000Z_

…which suggests an 8 day grace period. I wasn't sure what "synchronize" meant in this context, but this forum question: https://community.office365.com/en-us/f/156/t/292728

…tells us “The situation described is for the ADFS environment. If you only enable DirSync (we do), the activation window will be prompted”. This seems to be the answer to our problem.

Also, this article confirm this:

https://technet.microsoft.com/en-us/library/jj733593.aspx

If the user’s credentials are not federated, logging into Office 365 and authentication occur through a web browser. Users are directed to the Office 365 sign-in service page, where they type their Microsoft Online Services ID and password. The sign-in service authenticates their credentials and generates a service token that the web browser posts to the requested service and logs in the users.

Note:

You can integrate cloud IDs into your on-premises infrastructure by subscribing to Office 365 and federating your on-premises identities with Office 365 Organization IDs. This enables users to keep their Active Directory logins and also have an associated cloud ID that allows roaming settings.

With our RDS environment the “localappdata” folder is deleted at logoff which suggests that, as we currently only synchronize with DirSync, they should ALWAYS be required to re-authenticate at logon.  Oddly, however, we’ve found that if users reboot their Thin Clients during the day (and in SOME cases overnight) the “localappdata” folder is still deleted but a new token is created without the users having to re-authenticate, as if there’s some sort of session that allows this to happen but I can’t identify what or how this works.

It seems clear that ADFS is the answer to removing our users regular need to reactivate but I'm keen to understand why its not more prevalent.

Can anyone suggest what's going on and why users don't have to ALWAYS reauthenticate?

If I've misunderstood something and ADFS isn't the right way forward, please enlighten me, also

Thanks, in advance for any help you can give.

Bill

Microsoft 365 and Office | Subscription, account, billing | For home | Windows

Locked Question. This question was migrated from the Microsoft Support Community. You can vote on whether it's helpful, but you can't add comments or replies or follow the question.

0 comments

Answer accepted by question author

Anonymous
2015-12-21T04:31:16+00:00

Hi Bill,

Rene may misunderstand your requirement.

As a result of your main query, ADFS will remove the need for the users to authenticate each time. So we don’t need to modify the above registry keys.

Regards,

Jiaxing Bian

Was this answer helpful?

0 comments

5 additional answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Anonymous
    2015-12-21T06:05:41+00:00

    Thanks Jiaxing

    That is the main question and how we're going to resolve our issues.

    I was wondering how some users still manage to silently re-authenticate,on some days, even though we don't currently have ADFS set up.

    The

    HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Common\Identity

    ...registry entry seems to have an expiry time of 1 hour which would explain how users can logoff and back on without having to immediately reauth, but not the overnight ones.

    I did wonder if the "Keep me logged on" option has something to do with it and found this suggestion:

    Here's how to make "Keep me signed in" work:

    Go to Internet Options » Security tab » Trusted sites » Sites button. Then add the following entries:

    •https://*.microsoftonline.com

    •https://*.outlook.com

    •https://*.sharepoint.com

    You should leave "Require server verification (https:) for all sites in this zone" checked. Close it out. Then close your browser, open IE again and log in to Office 365, checking "Keep me signed in". Once you are in, you can try closing IE and then opening your Office 365 site again. You should be automagically signed in.

    If anyone can explain, that would be great

    Was this answer helpful?

    0 comments
  2. Anonymous
    2015-12-20T05:22:23+00:00

    Hi Bill,

    For your concern about authenticating Office applications with ADFS, we will consult the related team, and update with the right information soon. Thanks for your understanding.

    Regards,

    Jiaxing Bian

    Was this answer helpful?

    0 comments
  3. Anonymous
    2015-12-19T10:32:02+00:00

    Rene,

    Thanks for the quick feedback.

    My main  query is: could you confirm that setting up ADFS will permanently remove the need for users to manually authenticate when they use one of the Office ProPlus apps (e.g. Outllook) in our scenario?

    With regard to the currently irregular need for users to reauthenticate at logon, are you're saying that this registry entry is created along with the license key, as a result of the authentication?

    I can see if this registry key exists and check if it is removed when our users logoff their RDS session.

    I doubt that users of Outlook, Word or Excel would currently ever logout of O365 when they shut down their RDS sessions, though.

    In circumstances where authentication isn't currently required in a new session, are you suggesting that it is due to this registry key? If so, why wouldn't it always remove the need for reauthentication or does it have a short expiry date of its own?

    Sorry if I've not explained my question well enough. Let me know if you need more information

    Cheers

    Bill

    Was this answer helpful?

    0 comments
  4. Anonymous
    2015-12-19T09:04:33+00:00

    Hi Bill,

    I would like to have a quick confirmation on whether the user would sign out of the Office after he finish working with the application and close the client.

    You can have the user sign out, if not, and see the outcome.

    As licensing and activation process in Office 365 ProPlus works as "signing in to activate", in the case of SCA, if the Office possesses the licensed user's credential, activating can happen automatically behind the scenes as the Office 365 work or school account ID has been provided.

    If you would like to force users to sign in in this case, you may consider configuring to remove the following key and all of its subkeys from the Registry after every rebooting, which is to remove user's credentials in Office.

    For Office 2013 version of Office 365 ProPlus:

    HKEY_CURRENT_USER\Software\Microsoft\Office\15.0\Common\Identity

    For Office 2016:

    HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Common\Identity

    We would appreciate your understanding.

    Rene

    NOTE: This page contains information about editing the registry. Before you edit the registry, make sure you understand how to restore it if a problem occurs. For information about how to do this, view the "Restoring the Registry" Help topic in Regedit.exe or the "Restoring a Registry Key" Help topic in Regedt32.exe.

    Modifying Registry incorrectly can cause serious problems that may require you to reinstall your operating system. Microsoft cannot guarantee that problems resulting from the incorrect use of Registry can be solved. Modify Registry at your own risk.

    Was this answer helpful?

    0 comments