.

[Felix]

.

Edited October 5, 2015 by Guest

[rmw]

Als je bij een FM-account authenticatie via externe server aanzet handelt FM inlog als volgt af.

 

Er wordt in de AD (Windows) of OD (Mac) gekeken in welke groepen de gebruiker is opgenomen.

Alle groepsnamen worden vervolgens gezocht in de FM-lijst met accounts die extern moeten worden ge-authenticeerd.

De eerste in de FM-lijst die overeenkomt met één van de groepen wordt gekozen en de privilegeset die daarbij hoort wordt gebruikt.

Daarom is de volgorde waarin de extern ge-authenticeerde accounts in FM staan ook van belang.

Binnen FM is de gebruiker gewoon onder zijn inlognaam bekend.

 

Als je op die manier bijvoorbeeld een 10-tal accounts in FM met de juiste privilegesets en groepen in AD/OD definieert kan je de indeling van de gebruikers per privilegeset dus regelen in AD/OD door gebruikers van de ene groep naar de andere over te hevelen.

 

LDAP is hier niet van toepassing.

 

HTH

 

rmw

[menno]

Als je dan precies wilt weten wie er inlogt, dan kan je dat (op windows wel te verstaan) weer doen door op het werkstation de user-naam op te vragen (ze zitten tenslotte via de LDAP / Acive directory aangesloten op het domein) via: Get ( DesktopPath ), Get ( DocumentsPath ) of Get ( TemporaryPath ) ....

Op een Mac gaat dat ook, maar de usernaam die daar uit volgt is vaak niet de naam waarmee je in de LDAP/AD/OD bent aangemeld. Wellicht dat je dat met applescript of shellscript kan uitvragen en dan is dit daarop ook bruikbaar.

 

Je zou met deze gegevens nu precies kunnen bepalen wie de database gebruikt. Voor privileges wellicht niet genoeg, maar je kan er prima mee vastleggen welke gebruiker een een of andere actie heeft uiitgevoerd.

[Felix]

.

Edited October 5, 2015 by Guest

[rmw]

Ik denk dat Get ( AccountName ) in deze situatie die groepsnaam gaat opleveren. Staat in Get ( UserName ) dan de gebruikersnaam?

 

Dat dacht ik eerst ook, maar dat is dus niet zo.

De gebruikersnaam waarmee men op de computer is ingelogd komt in Get(Accountname).

Get(Username) is de naam die in de voorkeuren van de FMclient installatie kan worden gezet.

De groepsnaam die gebruikt wordt om de privilegeset te vinden is niet terug te vragen in FM.

 

rmw

[Felix]

.

Edited October 5, 2015 by Guest

[mefm]

Als je bij een FM-account authenticatie via externe server aanzet handelt FM inlog als volgt af.

 

Er wordt in de AD (Windows) of OD (Mac) gekeken in welke groepen de gebruiker is opgenomen.

Alle groepsnamen worden vervolgens gezocht in de FM-lijst met accounts die extern moeten worden ge-authenticeerd.

De eerste in de FM-lijst die overeenkomt met één van de groepen wordt gekozen en de privilegeset die daarbij hoort wordt gebruikt.

Daarom is de volgorde waarin de extern ge-authenticeerde accounts in FM staan ook van belang.

Binnen FM is de gebruiker gewoon onder zijn inlognaam bekend.

 

Als je op die manier bijvoorbeeld een 10-tal accounts in FM met de juiste privilegesets en groepen in AD/OD definieert kan je de indeling van de gebruikers per privilegeset dus regelen in AD/OD door gebruikers van de ene groep naar de andere over te hevelen.

 

LDAP is hier niet van toepassing.

 

HTH

 

rmw

 

Hallo

 

Ik wil net geen gebruik maken van SSO, maar hoe doe ik dat?

 

Op de client heb ik de authentification op 'external server' staan, op de server staat 'Filemaker and external server accounts' aangevinkt.

Dit werkt goed, echter iets te goed, users dienen nu bij het openen van de database geen login meer in te geven, Filemaker gebruikt de gegevens van windows.

 

Op zich is dit handig, echter had ik toch graag een loginschermpje gehad waarin de user zijn naam en password dient in te geven zodat je onder een andere user dan windows user in filemaker kan inloggen.

De logingegevens dienen dan geverifierd te worden met de domain server.

 

Kan dit?

Hoe pak je dat aan?

 

Met dank

[Felix]

.

Edited October 5, 2015 by Guest

[rmw]

Als je bij opstarten de shift (windows) of alt (mac) ingedrukt houdt krijg je gewoon het inlogvenster.

Wat je daar invult, moet echter wel als FileMaker account in de database aanwezig zijn.

Het is niet mogelijk om als een andere AD/OD gebruiker in te loggen.

Dat moet door als een andere gebruiker op de computer in te loggen.

 

HTH

 

rmw

[Felix]

.

Edited October 5, 2015 by Guest

[rmw]

Volgens mij zijn SSO en Webdirect niet compatible.

Dat waren IWP en SSO ook niet.

 

De Webdirect Guide geeft het niet direct aan, maar ik lees het uit het volgende:

Hoofdstuk 4, pag 30

- Web users can open solutions without specifying a password if the Guest account is set up for web access or an account name and password are specified in the File Options dialog box in FileMaker Pro.

- If a solution developer creates a script that includes the Re-Login script step, web users can change their login accounts without leaving the solution (for example, to switch from the Guest account to an account with more privileges).

En de opmerking bij het gebruik van ODBC sources wijst ook in die richting:

Hoofdstuk 4, pag 35

Note If a solution is configured to use ODBC data source single sign-on, users will be prompted to enter authentication information when attempting to access the ODBC data source.

 

Ik ken FM lang genoeg om hier niet meer verbaasd over te zijn, maar het is wel weer zo'n 'net niet' oplossing...

 

rmw

[Felix]

.

Edited October 5, 2015 by Guest

[Peter Wagemans]

Ik wil net geen gebruik maken van SSO, maar hoe doe ik dat?

 

Op de client heb ik de authentification op 'external server' staan, op de server staat 'Filemaker and external server accounts' aangevinkt.

Dit werkt goed, echter iets te goed, users dienen nu bij het openen van de database geen login meer in te geven, Filemaker gebruikt de gegevens van windows.

 

Op zich is dit handig, echter had ik toch graag een loginschermpje gehad waarin de user zijn naam en password dient in te geven zodat je onder een andere user dan windows user in filemaker kan inloggen.

De logingegevens dienen dan geverifierd te worden met de domain server.

 

Kan dit?

Hoe pak je dat aan?

Maak een dummy table en een dummy layout die je als opstartlayout van de file instelt.

In je opstartscript:

Allow User Abort Off

Re-Login [ "no access" ; "Vad8ag4Doc6peJ" ] // dit is een account die alleen rechten op het inlog script heeft, hiervan schroef je dus alles rechten terug tot het minimum

Re-Login

If [ Get ( AccountName ) = "no access" or Get ( LastError ) ]

close file

End If

 

Puur even in theorie, maar dit moet werken.

[Peter Wagemans]

Je kan rond het SSO probleem werken als je ook de accountinformatie ergens hebt zitten.

De bewering "for all users of the database" is denk ik niet correct in de ODBC authenticatie dialoog va de DSN defintitie. Dit wordt - toch volgens de tests die ik hier net doe - netjes on runtime per sessie berekent.

 

Je kan dus een Get(AccountName) invullen en een password berekenen, als je een user tabel hebt met paswoorden, zodat je je met een ExecuteSQL het paswoord kan ophalen.

Niet helemaal koosjer natuurlijk.

Dat wordt het wel iets meer als je een user tabel hebt met access privs op record level. De administrators van de file kunnen echter nog wel ieders paswoord zien.

En het kan misschien wel helpen als je 500+ accounts toch een SSO wil geven.