Office 2016 and Sharepoint keychain item

AVmcclint
Honored Contributor

Here's the scenario: We connect to our internal Sharepoint site (sharepoint.company.com) and click on an Office document that opens in the appropriate Office 2016 app. As the program launches we're prompted to login to the sharepoint server. We login as needed. The document opens and all is right in the world. The problem we're having is that later if we go to another internal server (someotherserver.company.com) that requires us to login, we immediately get a popup that asks to use a keychain item. This is problematic because not all our *.company.com servers are tied into AD and kerberos. The different servers may have completely different IDs and/or PWs. I looked in my keychain and found the item in question and it is specifically tied to the sharepoint.company.com server. If I delete that keychain item and go to someotherserver.company.com we're no longer prompted to use a keychain item.... until we login to sharepoint through an Office app. Adding to the problem is the fact that this keychain item is not even named something that the end user could possibly know what it was tied to. It generates helpdesk calls. We just flat out don't want or need this "function". Is there a way to stop this from happening?
a69612e1960d455ca12af0f87426b898

3 REPLIES 3

asegura
Contributor

Here is a good post that you can read.

[https://www.benstegink.com/changing-office-365-irm-account-office-2016-mac/](link URL)

AVmcclint
Honored Contributor

I'm sorry, that article wasn't helpful at all. We aren't doing any IRM, the sharepoint documents we're opening aren't protected (the password prompt is to login to the SharePoint site itself), and none of the keys the article mentions exist in our keychains. thanks anyway.

bentoms
Release Candidate Programs Tester

@AVmcclint sounds like some auth settings in SharePoint or IIS.

SharePoint should really have "claims based auth" (read: Kerberos) as top priority then challenge etc second.

I've also been presented with similar when connecting to a SharePoint site via a TMG, but the SharePoint admins were able to resolve it on the SharePoint/TMG side