All entry points

[Charity]

I have been reading until I am blind.  I am just setting up server and creating new program.  This is using separation concept with two files.

 

But it will need to be used from both Mac and Windows and different versions as well as through web direct and iPad and iPhone and probably anything else possible.  So I read about Open Directory and Active Directory and external authentication and privileges and security.

 

But what if I need to use both?  Nothing works right now.  

 

Thank you.

[Wim Decorte]

Both AD and OD?  Why would you need both?  In any network / domain there can only be one master when it comes to holding accounts and groups.  That's the whole point of using an AD or OD, they are "domain controllers"

 

Can you explain a bit more?

[Steven H. Blackwell]

Yes, please tell us what your objective is.  Then we can likely devise a plan to meet those goals.

 

Steven

[Charity]

I am setting up security.  And people will be accessing the file from everywhere and not just the server.  We are looking ahead and although they reimbursed me for FMS13 and we are setting it up, they think we will need more so we might need to go to external servers which are more beefy than us and who specialise in that stuff since I know nothing.  And I do not know if it will be Mac or Windows or Citrix or something else.

 

If everyone is forced to complete an authorisation to gain access meaning their manager must enter them as a User and if I script that manager so they can add accounts to only that lower privilege then I think that everything should be handled just like as if it was served so I would only need FM to authenticate.  Our existing "network" is closed-circuit system which will not interface.  So if I do not need OD or AD then why use them?  Won't I still have to do the same work in the file security part?  Or am I supposed to set up AD on our new Fm server?  I thought that should be kept isolated.

 

They did not get the server I told them to get, info I got from you here and on FM TeckNet but instead they got the minimum.  And they want the maximum.  And they want it all right now.  They even mentioned getting citrix which I know is not able to run this and is not OD or AD, I guess.  Should I just set up the accounts I know we need and not worry right now about how they will be accessed?  Will it matter?  I do not know if I can plan for everything.  That was my question.  

 

Thank you very much for helping me.  All I can think of every day now is Comment's 'do they take us seriously' thread and how under-skilled I am to be doing this.  I told them I did not know hardware and servers but they said I could figure it out.  So that is what I am trying to do.  I have been making the file for 8 months with no server and now they want security and we have server but they also want some served with network and some served with web direct and iPad etc.

[Steven H. Blackwell]

OK, first things first.

 

1. Someone needs to make an assessment of the level of sensitivity of the data that will be in these files and the level of adverse impact to the organization if a breach occurs.  That assessment can guide your decisions about the level of security needed.

 

2.  Create in each file a Privilege Set for each role that will be using the system.  Assign that role the privileges it needs.

 

3.  When #2 is completed--and it can be an on-going process--you can create Accounts for each person who will access the files.  Those Accounts can be internal to the files, or they can be externally authenticated by Active Directory, Open Directory, or local server groups.  Each Account is assigned to one of the Privilege Sets you created in #2.  THis is done directly in the file for internal Accounts, or through matching Groups for external authentication.

 

4.  This system then propagates through to all client types:  FIleMaker Pro, FileMaker Pro, and WebDirect.™ When a user is challenged for credentials, the user enters his/her Account name and password.  if authenticated, the user has access to the files with the privileges granted in Step #2.

 

 

Finally, two other items.

 

If your server is not robust, you won't be using WebDirect for more than 4 or 5 users. Larger WebDirect deployments require very robust servers.

 

I would also recommend that you get someone who knows FileMaker Server and FileMaker security to come into your organization and give you some assistance before you deploy all of this. It sounds as if your situation is complex, and if you don;t do this correctly at the outset you're going to be plagued with issues.

 

Steven

[Fitch]

Should I just set up the accounts I know we need and not worry right now about how they will be accessed?  Will it matter?

Yes, just set up the accounts you need. Remain calm. What's most important to think about are the roles Steven mentioned. I.e., the privilege sets. Those are what control your security and are generally what your scripts will reference, not individual account names. The privilege sets must be set up in each file regardless of whether you use internal or external authentication, Citrix, WebDirect, etc. etc.

External authentication is essentially just a convenience, especially if your organization is already using AD or OD. The more files your solution comprises, and the more users you have, the greater the convenience: you only need to add the AD groups to each file (e.g., management, accounting, sales) rather than a FileMaker account for each user. The real magic is when you add a user to an AD group -- that user instantly has access to every FileMaker file that authenticates to that group. Sweet! (We have hundreds of users here, and dozens of files.)

Note: full access accounts should not use external authentication -- that's a security risk.

[Charity]

So I set up the accounts in Data.  But what about the UI?  It says they must be same but they can't be same because privileges are based upon different files.  So what is the same?  

 

So I name the Account Name as 'parts' and not a person's name?

 

"you only need to add the AD groups to each file (e.g., management, accounting, sales)"

 

Okay, so I make an AccountName of "Management" then create a privilege set and even if it is different privilege set in the UI than in Data, that is okay?  It just doesn't make sense that 'they must be the same in the files' but they can't be because the tables and fields the privileges apply against is different.

 

So an AD group is the Account Name?  How can I add an AD group?  I am close to giving up.  Nonetheless I appreciate everyone's help.  But truly, I am close to joining the navy instead.

[Charity]

Okay. I am going to create an account name which is name of the privilege set.  Then I will create the privilege set for the UI which should only be like two privilege sets because it is only layouts and stuff.

 

But I will create all of the privilege sets anyway.  Then do the same in Data.  It makes no sense since the privilege sets will have the same name but they will not have same information.  But I will just do it and see what is going to happen.

 

But I am insisting on a raise.  Nobody should go through this stuff for free.  This isn't fun like other FileMaker stuff.  

[Fitch]

Sounds like you might be getting close.

 

The AD groups are defined OUSIDE of FileMaker. That's a whole other topic.

 

INSIDE FileMaker, your account names will be the names of your AD groups. So let's say in your AD "Management" group you have Larry, Moe, and Curly. Now you create the externally authenticated "Management" account in each file. Voila -- Larry, Moe, and Curly now have access to those files, and you only had to add ONE account instead of THREE.

 

The privilege set associated with that account will be unique to each file, because think about it: you have different tables, layouts, and fields in each file, so if you're doing any kind of custom privileges, what works in one file will make no sense in another.

[Wim Decorte]

This isn't fun like other FileMaker stuff.  

 

Oh it is.  This should not be an after-thought, this should very much be front and center in everything you do throughout the solution.   It is only painful when you try to retro-fit it into something and it clashes with free-reign functionality.

 

If you are not comfortable with this, get comfortable.  It is not going to go away.

[Charity]

The AD groups are defined OUSIDE of FileMaker. That's a whole other topic.

 

INSIDE FileMaker, your account names will be the names of your AD groups. So let's say in your AD "Management" group you have Larry, Moe, and Curly. Now you create the externally authenticated "Management" account in each file. Voila -- Larry, Moe, and Curly now have access to those files, and you only had to add ONE account instead of THREE.

 

The privilege set associated with that account will be unique to each file, because think about it: you have different tables, layouts, and fields in each file, so if you're doing any kind of custom privileges, what works in one file will make no sense in another.

 

Oh this is what I was missing.  That it was outside of FM.  So really the Account Name should be the privilege set name or could be which to me would make sense.  So I read it is role based.  So when I think of roles and I name the Account Name the role and I make the privilege set apply to a role then it all makes sense.

 

I just hope it will work when it all comes together.  

 

 

If you are not comfortable with this, get comfortable.  It is not going to go away.

 

I appreciate your stern words on something so serious.  I stumbled upon the potential need to figure this out early and you have just confirmed it.  I do not even own an iPad and I have to make this work on one?   Soon I will have one I think but I cannot wait.

[Fitch]

I think this might help:

http://www.soliantconsulting.com/blog/2009/02/using-local-os-accounts-for-filemaker-external-authentication

It tells you how to use local accounts and groups with FileMaker authentication. Use this information to set up a test environment on your desktop to play in and get more comfortable with it.

[Charity]

It will certainly help; I have printed it and shall study it thoroughly tonight and you and everyone here are wonderful in helping me.  I am a bit limited because none of the computers are mine to mess with.  At home, it is my mom's Mac and at work it is the chains IT people who are very weird about what we do on them.

 

The decision was passed up to chain since they think we might need cloud WAN stuff instead.  They had put our purchase of the FMS machine on hold.  I do not think a WAN cloud server will be happy with me setting up maybe 20-40 account groups to service our stores will they?  Then again, everything seems impossible and strange right now so what do I know?

 

I could eliminate maybe 15 account groups if I handled them with script triggers instead but I read that it is not as safe.  Wim says this should be first.  But may the hardware or at least my own computer should be first.  I have pressed for my reimbursement where I went ahead and paid for FMS.  If I get that back, I can get a Mac I think.  I should be much better position then.  Yes I am way over my head.

 

Do you think a cloud WAN server person will let me administer on their server?  How do others do it if they must go cloud?  And if I am becoming a pest I shall back off.  Thank you so much.

[Wim Decorte]

There are different types of cloud hosting.  The simplest form is that your file ends up on a FMS that is shared with other customers.  The alternative is that you get a dedicated cloud server.  In the first scenario it is unlikely that they will allow you to administer the machine to the level that you can create accounts and groups in the OS.  If you have a dedicated cloud server then it really is the same as having your own and you will be able to do what you want.

 

Some important aspects to consider for cloud hosting:

- is the nature of your data such that it is ok to be outside of your custody?

- WAN is going to be slower than LAN so the design of the solution needs to take that into account in a big way

- you will not be able to take advantage of SSO (if that was in the cards for a LAN deployment).

 

You say:

 

 

I could eliminate maybe 15 account groups if I handled them with script triggers instead but I read that it is not as safe.  

 

That can't be true.  It really can't.  Once you define a functional / security role in your database then it should be implemented in the security scheme as a privilege set.  You can not choose to avoid adding a role by using script triggers and other layouts/records "trickery"

 

I've attached a spreadsheet that I typically use to define roles and what they should and should not be able to do in a solution.  The columns are functions/tasks in the solution, the rows are groups/roles.  Go through that excercise and se how many real roles you come up with.

 

security_matrix.xlsx.zip