Admin wants to be able to log in as any user

[mr_vodka]

Hi guys,

Here is a situation that I am coming up against...

I have been sellig the idea of moving to External Authentication for the redesigned application that I am building. They have been cautious with my suggestions of moving to EA/AD. When I finally thought I was getting close to them agreeing with me, a point was made in which I could not directly give an answer for.

Currently, the system admin can go and troubleshoot a user's account by logging in as that particular user and seeing what goes wrong. Their concern is that if we move to EA that they will no longer be able to log in as a particular user because the AD password can not be shared due to company policy.

So, I said to them that we will be able to create a user account without going through EA if we need to troubleshoot because Fm can handle both. Do you think this is the best way to handle this or is there a better way?

They also wanted a way to enable and disable accounts. How can they easily do this without going through the IT dept to make changes to the AD settings. It takes forever and a lot of paperwork to get them to do something simple as changing group settings for a user.

Finally, I am still hoping that someone can answer the question I had in my other thread. It would help a lot to have an arguement stating that we could use possibly use the info coming out of AD/LADP.

TIA.

[Steven H. Blackwell]

So, I said to them that we will be able to create a user account without going through EA if we need to troubleshoot because Fm can handle both. Do you think this is the best way to handle this or is there a better way?

Two ways to address this:

1. Create a specific internal FMP Account for each privilege set for the IT people to use for testing. Unless a user account has a specific test, this will work.

2. Create an AD account for IT use in each Group that accesses the FMP files.

If you disable an externally authenticated Account from within FMP, you will disable the entire Group. The whole premise behind External Server Authentication is that the Accounts are managed externally, not within FMP. So if a user leaves, as soon as his main AD account is deprovisioned, he is out of the system.

HTH

Steven

[Steven H. Blackwell]

Finally, I am still hoping that someone can answer the question I had in my other thread. It would help a lot to have an arguement stating that we could use possibly use the info coming out of AD/LADP.

What is it you're trying to do here?

Steven

[mr_vodka]

1. Create a specific internal FMP Account for each privilege set for the IT people to use for testing. Unless a user account has a specific test, this will work.

2. Create an AD account for IT use in each Group that accesses the FMP files.

Hi Steven, this is what I was talking about. I thought that maybe we could create internal accounts and then have them use that.

As for creating additional AD accounts, I already have test accounts setup to handle this.

The only drawback to this method is that some things are tied to the user name such as viewing specific records etc, assignment of records, which they will now not be able to do considering that the test user names would be different.

If you disable an externally authenticated Account from within FMP, you will disable the entire Group. The whole premise behind External Server Authentication is that the Accounts are managed externally, not within FMP. So if a user leaves, as soon as his main AD account is deprovisioned, he is out of the system.

This is preceisely what I assumed. I guess I will have to have a flag in the user preferences table that the Admin will have to change that will validate on the opening script.

Thank you.

[mr_vodka]

What is it you're trying to do here?

Steven

Steven, I want to see if it possible to get the user information stored in the AD object such as employee telephone number, location, etc. This way the admin would not have to manually type all of this again into FM. Currently, they enter all the info into the the User Preferences table.

I know this really is not directly related to external authentication, but since it does use Acitive Directory to quthenticate, I was wandering if there was a way to get the info from the object component as well.

[Steven H. Blackwell]

The only drawback to this method is that some things are tied to the user name such as viewing specific records etc, assignment of records, which they will now not be able to do considering that the test user names would be different.

OK, this is an architectural error in the security schema. Such items should be role specirfic, i.e. Privilege Set based and not Account based.

Steven

[Steven H. Blackwell]

I want to see if it possible to get the user information stored in the AD object such as employee telephone number, location, etc. This way the admin would not have to manually type all of this again into FM. Currently, they enter all the info into the the User Preferences table.

Maybe with PHP or with fmDotnet you could query AD to get this information and put it into FileMaker Pro via the FileMaker Server.

Steven

[mr_vodka]

OK, this is an architectural error in the security schema. Such items should be role specirfic, i.e. Privilege Set based and not Account based.

Well this is true for accessibility based on privilege sets. But there are times that a user needs to only see their specific records. How else would one accommodate for that? I dont believe that you can rely on Priv Set alone in building a viable solution. For most things, yes using the priv set would be suffice, but again as we all know, clients want to lock down records to a user specific role. Your recommendation is not to use this kind of architecture, but then what to do? So is this a catch 22 then?

Thanks.

[Steven H. Blackwell]

Record level Access via the Privilege Set based on the Account Name will do this. In that instance you can modify the RLA test from the Get(AccountName) to use the value in a global field. That can raise the vulnerability level slightly; however I would venture to say that the system could be tightened down around that global such that only the IT manager could access it.

Thanks for clarifying what you're trying to do. It makes more sense now.

Steven