AnsweredAssumed Answered

SSO on an unmanaged device

Question asked by andre65 on Apr 4, 2018
Latest reply on Apr 12, 2018 by andre65

Like • Show 0 Likes0
Comment • 6

Hi,

We have a lot of databases (275) on 7 FM servers (13 and 15)
Users are connected thru the external server (AD server (all in one AD group))
The unmanaged device has an self-created username and password. (like username Piet and password Whatever )
On the windows (unmanned) device they connect to our wifi with there AD credentials ;

username : puk.p

pasword : welcome01

If they are opening a database the SSO (Single Sign On) takes over and opens the database in de background with puk.p and password welcome01. The AD account.

Because this is an unmanaged device we want all those users get the FileMaker loginwindow to identify them.
With SSO they don't get this !!

Devices are sometimes lent out and wifi is connecting automatically (ICT has no influence on this).
If this happens we (or the user) has a problem !!!

How can we prevent this from happening? Can I prevent FileMaker is using this SSO

My first solution is a re-login script?

I found out that Windows is using a Windows Credential called '*Session'.
If I change or delete this FileMaker shows me the login window.

Greetings
Andre Vink

Attachments

Unknown-1.png14.5 KB
Unknown.png60.1 KB

No one else has this question

Outcomes

wimdecorte Apr 4, 2018 2:40 PM

Pietje Puk... had to smile, childhood memories.

There may be some confusion at play here. SSO is not really possible from a device. SSO for logging into FM only works in the scenario that:

- FMS is on windows and the server is a member of the AD domain

- user is on a windows machine that is also ma member of the AD domain

- user is already logged into the machine using AD credentials

- FMS is setup to use External and FM accounts

- the file has a external accounts with at least one that the user's AD account belongs to

What you may be seeing is not SSO but possibly keychain-stored credentials. Which makes it look like/behave SSO but it isn't. Is this device iOS?

The screenshots have me confused: is this a Windows mobile device / Surface? Or did you mean 'laptop' and device in a more general term?

Actions

andre65 @ wimdecorte on Apr 5, 2018 7:53 AM

Hoi Wim,

It's a windows 10 laptop with eduroam (university network) and keychain-stored allowed in the application.

The screenshots are from that windows 10 device.

Add a little scheme of how we connect to network and FileMaker to our Databases

And file options. No KeyChain Access set or Sign Up.

With these settings, users are logged in, which I do not want.

Especially not on unmanaged laptops.

Actions

wimdecorte @ andre65 on Apr 5, 2018 8:05 AM

Ok, what I see happening from that diagram (especially the RADIUS) part is that the user gets automatically authenticated to the AD network with a pre-set AD account (session). And since that session account seems to be belong to an AD group that matches an external account in the FM solution, they get true SSO.

The only way to stop this (short of not using RADIUS) is to make sure that the session account is not in the AD group used for authentication to the FM solution.

1 person found this helpful

Actions

andre65 Apr 11, 2018 5:32 AM

OK. I see my reaction isn't saved? ( my mistake I think )

After a few days of testing and thinking.... I can't do anything about it.
In a few weeks we are migrating to FileMaker server 16.
In FileMaker Pro 16 there is an option to login with Azure.
Hope this will work, but don't sure? It shall be the same user account as our local AD.

Actions

wimdecorte @ andre65 on Apr 11, 2018 5:46 AM

I don't see how Azure would help unless you completely kill the existing AD integration. Which may not be what IT wants.

What about my earlier suggestion to make sure the *session account is not in the AD group used for FM access?

Actions

andre65 @ wimdecorte on Apr 12, 2018 7:40 AM

I've made an other AD group but same account name in it and that didn't work either.
I have about 1,300 colleagues who can log in to FileMaker. They use there account name every where.

I hope Azure (in the cloud) is not aware of the session in windows ( I hope ).

The other solution is to make an authorization layer in the application. If you're puk.p you not allowed see some layouts or see nothing at all.(only splash screen with "no access" on it).

About 150 application don't have this authorization... most of the applications where made in the '90. Every time updatet to the latest version.
So I have to catch up on some work :-)

Actions

6 Replies

wimdecorte Apr 4, 2018 2:40 PM
Mark Correct
Correct Answer
Pietje Puk... had to smile, childhood memories.

There may be some confusion at play here. SSO is not really possible from a device. SSO for logging into FM only works in the scenario that:
- FMS is on windows and the server is a member of the AD domain
- user is on a windows machine that is also ma member of the AD domain
- user is already logged into the machine using AD credentials
- FMS is setup to use External and FM accounts
- the file has a external accounts with at least one that the user's AD account belongs to

What you may be seeing is not SSO but possibly keychain-stored credentials. Which makes it look like/behave SSO but it isn't. Is this device iOS?
The screenshots have me confused: is this a Windows mobile device / Surface? Or did you mean 'laptop' and device in a more general term?
Like • Show 0 Likes0
Actions
andre65 @ wimdecorte on Apr 5, 2018 7:53 AM
Mark Correct
Correct Answer
Hoi Wim,
It's a windows 10 laptop with eduroam (university network) and keychain-stored allowed in the application.
The screenshots are from that windows 10 device.
Add a little scheme of how we connect to network and FileMaker to our Databases

And file options. No KeyChain Access set or Sign Up.

With these settings, users are logged in, which I do not want.
Especially not on unmanaged laptops.
Like • Show 0 Likes0
Actions
wimdecorte @ andre65 on Apr 5, 2018 8:05 AM
Mark Correct
Correct Answer
Ok, what I see happening from that diagram (especially the RADIUS) part is that the user gets automatically authenticated to the AD network with a pre-set AD account (session). And since that session account seems to be belong to an AD group that matches an external account in the FM solution, they get true SSO.

The only way to stop this (short of not using RADIUS) is to make sure that the session account is not in the AD group used for authentication to the FM solution.
1 person found this helpful
Like • Show 1 Like1
Actions
andre65 Apr 11, 2018 5:32 AM
Mark Correct
Correct Answer
OK. I see my reaction isn't saved? ( my mistake I think )

After a few days of testing and thinking.... I can't do anything about it.
In a few weeks we are migrating to FileMaker server 16.
In FileMaker Pro 16 there is an option to login with Azure.
Hope this will work, but don't sure? It shall be the same user account as our local AD.
Like • Show 0 Likes0
Actions
wimdecorte @ andre65 on Apr 11, 2018 5:46 AM
Mark Correct
Correct Answer
I don't see how Azure would help unless you completely kill the existing AD integration. Which may not be what IT wants.

What about my earlier suggestion to make sure the *session account is not in the AD group used for FM access?
Like • Show 0 Likes0
Actions
andre65 @ wimdecorte on Apr 12, 2018 7:40 AM
Mark Correct
Correct Answer
I've made an other AD group but same account name in it and that didn't work either.
I have about 1,300 colleagues who can log in to FileMaker. They use there account name every where.
I hope Azure (in the cloud) is not aware of the session in windows ( I hope ).

The other solution is to make an authorization layer in the application. If you're puk.p you not allowed see some layouts or see nothing at all.(only splash screen with "no access" on it).
About 150 application don't have this authorization... most of the applications where made in the '90. Every time updatet to the latest version.
So I have to catch up on some work :-)
Like • Show 0 Likes0
Actions

SSO on an unmanaged device

Attachments

Outcomes

Related Content

Recommended Content