One of the things that often comes up from this type of application is that they want you to dumb down the conversation between the app and the servers. They like to perform ldap authentication (I HATE that term for what it's worth) and you want to be sure they're not passing creds in the clear. That would be a common gotcha.
Another piece to ask about is what they use for their authentication protocol at all. If not LDAP (ewwww) then what? NTLM? KERB? ?
How do they find users in the domain? That's important because you don't want them to hinder your ability to reorganize within OU's should the need arise. If native auth is how they operate, then there would be no reason to block movement of secprins.
Those are some things off the top of my head. But most of what you're looking for is how they interact with AD. If LDAP, how do they plan to protect the conversation and what's involved? If not, then what? What limitations are they going to impose due to this application that you would otherwise not have a thought about?
Al
On 9/19/06, John Singler <[EMAIL PROTECTED]> wrote:
Greetings -
We have a 3rd party vendor who wants to tie their web app into our AD
for authentication and authorization. (This is an app that has already
been purchased and is in-house but uses a local db for AAA).
What, specifically, should I be asking them about their application so
as to keep our environment in its secure and stable state?
AFAIK, all they have 'asked' for is a U/P with read access to users and
groups. Obviously, they aren't getting anything until we work out the
details.
Curious as to what other orgs consider when in similar circumstances.
Environment (FWIW):
Single forest, single domain. All DCs w2k3 SP1, FFL/DFL are w2k3.
tia,
john
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.activedir.org/ml/threads.aspx
