HRESULT: 0X80070490 with Azman and AD LDS on 2008 server

[Ken]

Hi,
I'm developing a WPF application which is using AzMan as its policy store.
The AzMan in configured to work with AD LDS (aka ADAM). The development
environment was with 2003 server and everything was fine. The deployment
environment has 2008 server and when I'm trying to run the application I get
an exception: "Element not found. (Exception from HRESULT: 0X80070490)". The
stack trace points to
AZROLESLib.AZAuthorizationStoreClass.OpenApplication2(String
bstrApplicationName, Object varReserved). I call this method with "MyApp" and
null and it was working fine on 2003 box.
It seems to me that the application cannot locate "MyApp" in my AzMan store.
Does The AZMan API expect something different on 2008 than on 2003? Do I need
to replace interop.AZROLESLib.dll to a newer version?

 

[Joe Kaplan]

Are you sure your app has the right read permissions to the ADAM data? I'm
guessing the app would be using Windows auth to bind to the ADAM LDAP server
and uses the process identity of the app pool (typically network service) to
do this. That would mean that you would either need to grant the machine
account for the domain computer object for the machine read access to ADAM
or something more general (I typically give "authenticated users" read
access in ADAM unless there is something really sensitive in there that
requires specific restrictions).

The error you are getting is not very helpful at all, but this could just be
some sort of operational problem related to not being app to read the data.
In LDAP, if you try to read data that you don't have permission to see, the
result to the client is that it simply doesn't exist. You don't get an
access denied error.

If there was a failure to authenticate, at the LDAP layer you'd likely get
an "operations error" from ADAM in this case.

HTH!

 

[Ken]

Hi Joe,
Thank you. I tried to give permission on ADAM for authenticated users but I
got the same error. I actually think that the problem is not with access
right as the call:
azStore.Initialize(0, appStoreLocation, null) is returning with no
exceptions. It is the azStore.OpenApplication2(appName, null) call which
return the 'element not found' exception. So I suspect the appName is not
found in the ADAM store but I don't know why. The same calls works great
with 2003 server... Any other ideas?
--
Thank you,
Ken

Are you sure your app has the right read permissions to the ADAM data? I'm
guessing the app would be using Windows auth to bind to the ADAM LDAP server
and uses the process identity of the app pool (typically network service) to
do this. That would mean that you would either need to grant the machine
account for the domain computer object for the machine read access to ADAM
or something more general (I typically give "authenticated users" read
access in ADAM unless there is something really sensitive in there that
requires specific restrictions).

The error you are getting is not very helpful at all, but this could just be
some sort of operational problem related to not being app to read the data.
In LDAP, if you try to read data that you don't have permission to see, the
result to the client is that it simply doesn't exist. You don't get an
access denied error.

If there was a failure to authenticate, at the LDAP layer you'd likely get
an "operations error" from ADAM in this case.

HTH!

 

[Joe Kaplan]

Are you sure all the data is stored in ADAM/LDS as expected? I think I'd
probably use the ldp.exe tool that comes with ADAM to look at the data in
both servers and see if it looks the same. Maybe there is something messed
up with the actual data in the directory. You might also try a tool like
LDIFDE to export the data into a text file.

I really don't have any other ideas but if the store is initializing just
fine.

--
Joe Kaplan-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services Programming"
http://www.directoryprogramming.net

Hi Joe,
Thank you. I tried to give permission on ADAM for authenticated users but
I
got the same error. I actually think that the problem is not with access
right as the call:
azStore.Initialize(0, appStoreLocation, null) is returning with no
exceptions. It is the azStore.OpenApplication2(appName, null) call which
return the 'element not found' exception. So I suspect the appName is not
found in the ADAM store but I don't know why. The same calls works great
with 2003 server... Any other ideas?

 

[Ken]

Thank you Joe.
I used the ldp.exe and indeed found that in the 2003 server the content of
my root directory (DC=myDomain,DC=local) includes a configuration file which
is missing on the 2008 machine. Is there some configuration on the 2008
server which prevent the configuration file from being created? How can I
correct it?

 

[Joe Kaplan]

That I have no idea on. However, it may be that you are either missing some
part of the AzMan schema for your LDS server or that some aspect of the MMC
snap-in that manages AzMan and persists the policy didn't save all the
objects correctly.

I don't know exactly what you mean by a "configuration file" underneath the
root as the directory doesn't contain files. It contains objects that have
attributes which store data and those objects may also be containers that
hold other objects.

But, I'd definitely poke around with AzMan to try to ensure that the policy
is saved correctly.

 

[Ken]

Thank you Joe.
Inside the ldp.exe when I dbl-click the root directory, part of what I get is:
1> configurationFile: <?xml version="1.0"?>
<doc>
<configuration>
<description>sample Adamsync configuration file</description>
<security-mode>object</security-mode>
<source-ad-name>myDomain.local</source-ad-name>
<source-ad-partition>dc=myDomain,dc=local</source-ad-partition>
<source-ad-account></source-ad-account>
<account-domain></account-domain>
<target-dn>dc=myDomain,dc=local</target-dn>
<query>
<base-dn>ou=tplss accounts,dc=myDomain,dc=local</base-dn>
and do on...
I can't see it on the 2008 machine.

 

[Joe Kaplan]

Ok, that's an attribute called "configurationFile" that contains a string
that has some XML in it. It sounds like this attribute has been added to
the class schema for the root object type (domainDNS is what you are using)
or probably it was added to the "top" class which is the base of all the
schema types.

However, that's an ADAMSync config file, not something having to do with
AzMan. As such I'm not sure it is related at all.

Where is the AzMan data in both directories?

 

[Ken]

Hi Joe,
You're right. I missing a lot of AzMan data in the AD LDS of the 2008
machine: there's no OU=MyDomain Accounts,DC=MyDomain,DC=LOCAL node and the
ForeignSecurityPrincipal Node is almost empty. I don't know what could have
caused it and how come my AzMan contains all the right information? Where
does it actually stores it if I can't see it in the AD LDS?

 

[Joe Kaplan]

Is it possible the snap-in is referencing the old ADAM server instead of the
new LDS instance?

One easy way to have done this would have been to make the LDS server a
replica in a configuration set with the original ADAM so that AzMan could
basically use either store interchangeably and you could master the actual
policy information from either of them.

However, it sounds like you might need to do some sort of export/import or
something. It is a little hard to visualize without seeing it, but I
suspect that there is a simple explanation here somewhere.

 

[Ken]

So I unistall everything and re-started from scratch following this link:
http://msdn.microsoft.com/en-us/library/ms998331.aspx (though my app is WPF
and not ASP. This was the best official documentation I could find). Now I
see all the Azman information inside ADAM as it should be. BUT, I still get
the exception above!

 

[Joe Kaplan]

I'm out of ideas then. You may need to go to MS support on this. Maybe one
of the guys who monitors the newsgroup will pick this up.

At least your ADAM/LDS is in better shape now.