ECP and Office365

[John Morrison]

On Thu, 2016-12-15 at 14:59 +0000, Cantor, Scott wrote:
> > With the use of ECP and microsoft outlook rich clients, we have an issue
> > when having our UPN or EPPN scoped attribute as the email address
> > instead of the uid at domain correct format.

> Those are the same format, so I can't quite understand your point there.
> 

firsname.lastname at domain.x is not the same as uid at domain.x thats what i
mean, sorry if that wasn't clear.

But anyway, this is just Outlook stripping the mail account to login. Or
UPN in other cases. When using outlook for office365, they use the UPN
as the mail account. Thats microsoft.  

> > Is there a way to rewrite this in the apache config or in the auth flows
> > on ECP to somehow search out the correct user based on this part, with
> > some LDAP wild card instead?
> 
> If you need to handle different kinds of authentication lookup, that depends on how you're doing authentication, but with LDAP you have whatever capability you want, really, you can use combinations of search filters and things like that. You need to either leverage the subject canonicalization features after authentication to get the username back out normalized into a consistent form or you would have to accomodate different types of username formats in the attribute resolver.
> 

Right, but our IdP uses uid=uid globally. How I would search/auth a user
via uid=firstname.lastname would be tricky to correct if coming from the
ECP way.


 DEBUG
[net.shibboleth.idp.authn.impl.ValidateUsernamePasswordAgainstLDAP:131]
- Profile Action ValidateUsernamePasswordAgainstLDAP: Attempting to
authenticate user test.person.3743
2016-12-16 16:12:08,042 - INFO
[net.shibboleth.idp.authn.impl.ValidateUsernamePasswordAgainstLDAP:152]
- Profile Action ValidateUsernamePasswordAgainstLDAP: Login by
'test.person.3743' failed


> > We have got the Office working well with SAML only for now. Our ECP is
> > protected via apache ldap location config.
> 
> Well, my advice is to not to do that and use the IdP directly, I guess, but absent that it's not really an issue for me to weigh in on since it's not the IdP doing the authentication.
>  

Right!, thats a good point...  I thought it had to be protected. I've
taken that away now.

> -- Scott
> 

After making an account with the proper UPN uid at domain:

I find out now that the autodiscovery for office 365 doesn't work well
with ECP for some strange reason.  The STS token via ECP works
correctly. It is sent up to Azure correctly and works. But like i said,
this autodiscover it acting up.

On the other hand, there is an option to user OAuth2 in Azure and this
avoids ECP and uses SAML instead. And works well with outlook rich
clients. But as far as other clients like thunderbird and mail in the
mac, they have no way of understanding OAuth. 

So this is the deal breaker to now use ADFS instead, for Office365.


      <Analyzer>^M
        <Title>We're running checks to verify the authentication
endpoint for "uid at test.xx.xx.xx".</Title>^M
        <Result>True</Result>^M
        <Duration>00:00:03</Duration>^M
        <ResultTitle>We didn't find any problems with your Office 365
sign-in credentials.</ResultTitle>^M
        <ResultUserMessage>We didn't find any problems with your Office
365 sign-in credentials.</ResultUserMessage>^M
        <ResultAdminMessage />^M



    <Analyzer>^M
      <Title>We're running Azure AD active sign-in checks on your
account: uid at test.xx.xx.xx.</Title>^M
      <Result>True</Result>^M
      <Duration>00:00:01</Duration>^M
      <ResultTitle>We successfully submitted your security token.
</ResultTitle>^M
      <ResultUserMessage>We verified your Office 365 credentials. Azure
Active Directory accepted the token from your identity
provider.</ResultUserMessage>^M
      <ResultAdminMessage />^M


      <Analyzer>^M
        <Title>Attempting to test autodiscover service for
"uid at test.xx.xx.xx".</Title>^M
        <Result />^M
        <Duration>00:06:26</Duration>^M
        <ResultTitle>We failed to obtain proper Office 365 user
settings</ResultTitle>^M
        <ResultUserMessage>HTTP 503:
ServiceUnavailable</ResultUserMessage>^M

<ResultAdminMessage>ServiceStatus=ServiceUnavailable</ResultAdminMessage>^M

<ResultSupportMessage>ServerName=0dt43gdgsdg</ResultSupportMessage>^M
        <AdvancedHttpResponseInfo />^M


      <Title>Remotely executed:
Microsoft.Online.CSE.HRC.Analysis.Analyzers.RemoteCmdlets.StsConnectivityAnalyzer</Title>^M
      <Result>True</Result>^M
      <Duration>00:00:00</Duration>^M
      <ResultTitle>We could not contact our servers to diagnose your
problem. The result of the remote job
Microsoft.Online.CSE.HRC.Analysis.Analyzers.RemoteCmdlets.StsConnectivityAnalyzer could not be retrieved.</ResultTitle>^M
      <ResultUserMessage>User is not validated. Cannot run
command.</ResultUserMessage>^M
      <ResultAdminMessage />^M


But this is out of the shib scope. Unless someone else out there might
tell me how they got shibv3 to work with Office365 when it comes to the
rich clients using ECP.

Kind regards,

John