External Auth - UPN - other suffix...

[RII]

Hello All,

I've a peculiar issue regarding external authentication using UPN. We are serving our particular project on WebDirect.

Filemaker Server 18

We have two companies, CoA and CoB

CoA has one forest/one domain, but multiple UPN suffixes for different sub-companies:  CoA1, CoA2

CoB has one forest/one domain, single UPN suffix

Two-way trust established and working well as Users are able to login with CoA UPN and Users are able to login with CoB UPN

 

The problem starts when a user from CoA1 tries to login - It won't authenticate and an error is given saying that they don't have access.

If the user only uses the SAMAccount name, they are able to login properly.

 

I've even tried with a plain blank database trying to isolate my terrible programming/configuration... still no luck...

 

My thoughts on this after banging my head is that somehow the AD authentication / FilemakerServer isn't handing the alternate UPN suffix properly..?

 

Your thoughts are greatly appreciated!  

Richard

[Wim Decorte]

Hi Richard,

A couple of questions.

What domain is the FMS machine a member of?

How are the multiple UPN suffices set up? and how are users assigned to each of those?

Can the user log in with the UNC syntax for CoA1?

A more general question: how important is it to the solution to have the users log in with the UPN syntax, what's the underlying business logic?Insert other media

[RII]

Wim,

Thanks for the great questions!!!

FMS is member of domain CoA

 UPN suffixes are setup under AD Domains and Trusts.  Users are assigned based on their company/division.

User can login with UPN format for main domain (CoA) but a user cannot login with UPN format for CoA1 (alternative suffix inside CoA domain)

Answering your business logic question, with WebDirect/FMS doing the external authentication - it would be possible to have two James Smiths.. or two jsmith  between multiple companies when using the SAMaccout Name so I'm wanting to use UPN as a distinctive username for login.

The CoA and CoB are two forest (different companies owned by same parent company) with a two way trust.

I fully understand the concept of having the users maintained within the database, but that makes for a complicated setup when we can just assign the right user security group in AD as staff are hired/terminated.  

 

-richard

Edited August 30, 2019 by RII

[Wim Decorte]

And just to confirm the ultimate test: the users can log into their workstations with the UPN account syntaxes?  All of them?

As to the underlying business logic: you cannot enforce the UPN syntax, the user may still just provide their account name without UPN or UNC format, unless you do some post-login validation on the Get(AccountName) to kick them back out.

Did you try the UNC format?

[RII]

Users can login to the workstations with UPN syntax using the original domain as well as the additional suffixes.

We are doing a check for upn format "@" after the user is validated by external auth.

 

UNC format works for the original domain - does not work for the additional suffix items.

That is something I would expect as we don't have domains with those names so the UNC lookup is searching for a domain with that name and it can't find it.

\\domainA\username  <-works

\\domainA1\username   <- does not work.

 

-richard

Edited August 30, 2019 by RII