This should be a simple answer, but I can't seem to find it.

Is it possible to provision (create) users in Teradata from FIM? Teradata has an ODBC (and .NET) driver used in Windows all the time. So is there any reason why FIM can't have the ODBC driver installed, connect to Teradata, and run some SQL to create a user?

I would think this could be done with any database that has an available ODBC or .NET connector.

User would be added to AD - particular OU and or groups and this would populate Teradata.

If this is possible can anyone point me to some documentation? 

Thanks,

Andrew

• Edited by ChromeDome00 21 hours 18 minutes ago added info

I'm sure it could be done, but FIM's architecture isn't as you appear to be suggesting. There is nowhere in FIM to "install the ODBC driver". If Teradata has a SQL DB then FIM's SQL management agent may do the job by connecting directly to the DB otherwise you may need to write a custom MA using the ECMA framework. 

I'm not aware if this has been done before and doubt there is documentation specifically about Teradata. There is plenty of documentation on FIM and its architecture on TechNet and some (although not great IMHO) on the ECMA.

Regards,

Dave

Thanks - 

I was not looking for Teradata specific info - but anything that talks about doing some kind of custom connection to an ODBC/.NET available resource and then using a script with SQL statements to create or retrieve objects.

It sounds like i need to look up ECMA

If you can wait a couple of days I'm working on a document that describes how to build a simple a ECMA to do just that - talk to a simple SQL table. It might help with what you are trying to do.

Beside writing your own MA, you can also create an transfer table in an MS-SQL Server.
You can use SSIS for example to transfer data from an to this table, or maybe the teradata RDBMs can do this for you.

Another option is to Create a Linked Server Connection to the Teradata RDBMs, you can then use the FIM SQL MA to connect to teradata through the SQL Server.

Take a look at this article:
SQL to Teradata Linked Server

Writing an ECMA is not that magic but you have to maintain you own Development Solution, you schould check all the posted options and choose the one which fits best to you.

Regards
Peter 

Thanks to all:

1. Yes Dave, I would love to see your example - no rush, just trying to find options.

2. A linked server connection seems to be more overhead as I only want to populate Teradata with AD information - the feed only has to go one way; but if a Teradata admin did try to add a user directly (to bypass AD) it would be nice if the change were detected and deleted. 

Teradata allows for LDAP and or Kerberos logins - but Teradata still needs a matching username in either case. So, if a user is provisioned in AD, it would be nice to push that into Teradata. I guess i could do a linked table in SQL, but that just adds complexity to the solution. 

If we do row level security, we also have entries in security tables for each user, and if we do Mandatory Access Control, the same username row level security is needed. 

Also, Teradata has some features such as trusted sessions that allows users access via a BI Tool without having a username in Teradata. The username is granted a right to logon via a service account - but a user is not created in Teradata - this is easy to script both to add and remove the appropriate rights. 

We have our own custom solution that reads AD (via LDAP) and can then create users and make changes in Teradata, but if a customer has FIM, it would be nice to leverage it. 

It seems to me the linked server option would require almost as much development as writing the ECMA - I would still have to create the rules that populate the table in MSSQL.

I appreciate all the ideas - I will have to explore them. 

There are a few ISVs that provide FIM MAs for their customers, but not that many. Typically people rely on a specialist SI to write the custom MA. Given your business case it wouldn't be too hard (or costly) to write a packaged MA.

I understand... but many shops are convinced they want everything in one place and that they have the expertise to do it - so being able to show a generic SQL example is all I want to be able to do. 

If it becomes to hard for them, then that is a different issue. But I am hoping basic use cases are not that hard:

1. user added to AD group, user created in Teradata with Role corresponding to AD group

2. User removed from AD group user removed from Teradata role, and possibly deleted - maybe one AD group for Teradata users, and another AD group for a Teradata role - if users is removed from users group, they are deleted from Teradata DB. 

In this way one group can represent all users, and other groups would correspond to Teradata roles. The SQL is simple, just getting the trigger to fire in FIM and run the SQL is the part i need to understand more.