Extensible MA is Using FIM SynchService account instead of "connect" and "user" settings in MA configuration
-
Friday, June 15, 2012 6:40 PM
We have been using a standard set of AD and ADAM Extensible Managed Agents in MIIS / ILM over the last 8 years and now that I have migrated our entire environment to FIM2010, the only issue I have left to solve is connectivity to AD in 1 ECMA.
Our code is simple and I can see the .connect and .user variables being populated for connection to the AD Domain container but when the MA is run under FIM alone, it uses the FIM synch service to attempt the bind to AD rather than the account and password configured in the MA manager. I have refreshed it and even recreated it manually with the same result.
I have the latest updates installed, checked all of the published issues with no problems and all of my standard AD MAs (36 on 3 synch servers) are working fine with the same account.
Has anyone encountered this yet? I can hardcode the credentials into my ECMA DLL but I doubt that will work given the way it is running now, and I hate to embed IdM data in code.
Thanks
Mike Welborn
All Replies
-
Friday, June 15, 2012 6:46 PMModerator
Mike-
What does the code that's making the actual LDAP connection in your XMA look like?
My Book - Active Directory, 4th Edition
My Blog - www.briandesmond.com -
Friday, June 15, 2012 7:16 PM
I had to remove the proprietary naming of some of the objects. The actual bind is done by using the normal Dierctory Entry instantiation. The hasError variable gets set and I catch the exception. I also log the errors by using the ex.Message within the try section from another class. The VS 2010 code is compiled to refer to the Framework 4 DLLs on the server.
...................................................................................................................................................................................
Imports System.DirectoryServices
Imports System.Text
Public Class MyData
Dim ADObject As DirectoryEntry ' is the AD object
Dim Data As PropertyValueCollection
Public isDirty As Boolean ' true if object was changed
Public lastError As String ' contains the last error
Public hasData As Boolean
Public hasError As Boolean = False
' creates a new instance
' ADObject holds the directory object
Sub New(ByVal ADPath As String)
hasData = False ' init the hasdata flag
Try ' try to open/read AD object
ADObject = New DirectoryEntry(ADPath) ' get a new userobject
If ADObject.Properties.Contains("MyAttribute") Then ' if siemens-CATData attribute of the AD object has data
Data = ADObject.Properties.Item("MyAttribute") ' remember the data
hasData = True ' set the hasData flag
End If
Catch ex As Exception ' exception handling
lastError = ex.Message ' save error
hasData = False ' reset hasData flag
hasError = True ' set error flag
End Try
End Sub -
Friday, June 15, 2012 7:18 PMModerator
Are you impersonating anywhere? If not, you're never passing the creds from the XMA to the DirectoryEntry constructor so it will run in the context of the sync engine.
My Book - Active Directory, 4th Edition
My Blog - www.briandesmond.com -
Friday, June 15, 2012 7:27 PM
No, we use the generic ECMA IMV Class attributes that pass the Domain, account and passord to the DLL so impersonation in not needed. At least not until now. The ECMA framework code has always been able to pass the MA configuraton values to our DLL with no problems. It's a plain vanilla IMV interface .....
The m_domain, m_username and m_password attributes are passed from the MA configuration to the extension DLL and authentication is set.
Imports Microsoft.MetadirectoryServices
Imports System.IO
Imports System
Imports System.Data
Imports System.Data.SqlClientPublic Class MydataExport
Implements IMAExtensibleFileImport, IMAExtensibleCallExport
' constants
' variables
Private m_commandPath, m_logFile As String
Private m_UserName As String
Private m_Domain As String
Private m_Password As String
Private m_DC As String
Private m_FilePath As String
'Private swOut As StreamWriter
Private fileName As String = "MyFile.txt"
Private ConnectDB As String ' value of database
Private ConnectServer As String
Private ConnectTable As String
Private ConnectEnabled As Boolean -
Friday, June 15, 2012 7:28 PMModeratorYou're never passing them to the constructor on your DirectoryEntry though. There's no possible way from what you've pasted that the S.DS calls have any clue about the creds provided to the XMA.
My Book - Active Directory, 4th Edition
My Blog - www.briandesmond.com -
Friday, June 15, 2012 8:46 PM
The code is simple but there is a lot of it!
I have an overloaded NEW Class that passes these for the impersonation ... I sent you the wrong sub last time.
The ADPath are used together withe theusername and password for each bind.
I will take a look at the running code again on the ILM servers that are working again and let you know if I find it.
Thanks for the replies Brian!
Sub New(ByVal ADPath As String, ByVal username As String, ByVal password As String)
hasData = False ' init the hasdata flag
Try ' try to open/read AD object
ADObject = New DirectoryEntry(ADPath, username, password) ' get a new userobject
If ADObject.Properties.Contains("MyData") Then ' if siemens-CATData attribute of the AD object has data
Data = ADObject.Properties.Item("MyData") ' remember the data
hasData = True ' set the hasData flag
End If
Catch ex As Exception ' exception handling
lastError = ex.Message ' save error
hasData = False ' reset hasData flag
hasError = True ' set error flag
End Try
End Sub -
Friday, June 15, 2012 8:50 PMModeratorThat new sample appears accurate. I would go through and check all your writes to ADObject and make sure you're never reinitializing it. You could mark the field readonly and that would negate the ability to reinitialize it.
My Book - Active Directory, 4th Edition
My Blog - www.briandesmond.com
.png)
