WebADM Active Directory Object Class issues

[Tom Bean]

I am having problems registering or unregistering users in WebADM.

Currently, I got WebADM to work so I could use two factor authetication by adding "user" to the objectclass variable. This works but then it automatically registers hundreds of users in my domain, which is a problem when it comes to licenses.

I have found the main problem is trying to add the objectclass webadmAccount to the users objectclass. Using webadm I get a Server is Unwilling to Perform error and if I try to do it manually using ADSI Edit I get the following error:

---------------------------
ADSIEdit 
---------------------------
Operation failed. Error code: 0x2040
The specified method is not supported.


00002040: SvcErr: DSID-030F0E51, problem 5003 (WILL_NOT_PERFORM), data 0

---------------------------
OK   
---------------------------

What I wanted to find out is if anyone has had this issue before and how they had fixed it. Also, if it is possible to change this filter to look for a group assigned to a user rather than a field in objectClass as I do not seem to be able to change this.

Thanks.

[Administrators]

You should be able to un-register users. Two possible causes:

1) Check you have the latest WebADM version. Fixes were done recently
for de-registration of users.
2) Your administrator account must be AD Domain Admin.

[Tom Bean]

Hi, I am using the latest version, only installed late last week.

The administrator account is set to the account managing the domain, when I try to un-register a user I get the following error:

Objectclass user is not an extension.

Looks like it is trying to remove user from objectclass.

[Administrators]

Do you use AD 2003 ?

Because in 2003 LDAP does not work the way and WebADM has to handle
objectclasses another way.
In this case, to un-register just drop the webadmData attribute from
the users.

[Tom Bean]

Well, the domain was originally 2000, then 2003, now 2008 but I assume some sort of legacy issue is hanging around from 2003, so I went for your 2003 fix, however users without the webadmData attribute are still showing as registered:

So this screenshot shows a user without webadmData and still registered:

This screenshot shows a user with webadmData and correctly registered:

[Administrators]

*** If you have AD 2008 ***

Check your DC is 2008 and you AD has been raised to 2008 level.
in WebADM Infos Menu -> LDAP Server Details you should see both
"domainfunctionality" and "domaincontrollerfunctionality" with a value
>= 3. If lower, it means either DC or AD is in 2000/2003 compatibility
mode.

You need to use the setting in webadm.conf:
webadm_account_oclasses "webadmAccount"


*** If you have AD 2003 ***

You must use the configuration in webadm.conf:
webadm_account_oclasses "webadmAccount", "user"
To un-activate, you need to drop webadmData attributes.

On Mar 26, 11:39 am, Tom Bean <tom.b...@changingworkplace.com> wrote:
> Well, the domain was originally 2000, then 2003, now 2008 but I assume some
> sort of legacy issue is hanging around from 2003, so I went for your 2003
> fix, however users without the webadmData attribute are still showing as
> registered:
>
> So this screenshot shows a user without webadmData and still registered:
>

> <https://lh4.googleusercontent.com/-LHKEEDqe768/UVF6i8UnF4I/AAAAAAAAAC...>

>
> This screenshot shows a user with webadmData and correctly registered:
>

> <https://lh3.googleusercontent.com/-WgxEkqKdReI/UVF6qZP0j7I/AAAAAAAAAC...>

[Tom Bean]

Ok, so using the steps below both have a value of 4, so I am assuming it is set as AD 2008.

However, removing "user" from the webadm_account_oclasses deactivates all users, I then run into the same issues I mentioned in my first post where AD will refuse to add the objectclass to the users.

00002040: SvcErr: DSID-030F0E51, problem 5003 (WILL_NOT_PERFORM), data 0

[Administrators]

Ok so it's 2008-enabled AD.
So do not try to add the "user" to webadm_account_oclasses. This will
not work.

I suppose that the graphical setup went fine and that WebADM correctly
registered the schema updates to your AD?

Remains :
- Either a access right issue (excluded if you are logged as domain
admin).
- Bad information passed in the user extension wizard.

When you extend the user, can you show the wizard? Did you fill-in the
mandatory attributes (certainly none).
Does the problem occur when you click "extend"?

[Administrators]

Note: With ADSIEdit this is normal if it fails:
With the tool, you must drop the webadm-specific attributes when you
drop the oclass.
Same when you add the class, you must add all the mandatory attrs
when you add the class.

That's why it's much simpler to use the "Activate" button in
interface...

[Tom Bean]

Ah ok.

Yes the schema added fine.

Looking at the schema created for webadmAccount, the only mandatory fields are sAMAccount and cn, both of which already exist. When I click Activate, I only get prompted for optional attributes, and adding these in does not help either.

I am guessing its not a permissions issue as I can create groups, changes passwords, disable accounts, delete accounts, etc. using the web interface.

Where would I click extend?

[Administrators]

I meant "Activate" with "Extend".

I'm re-reading your first post and I realize the AD works like a 2003
here - as you managed to make it work by adding the user oclass to the
config.
In 2008, this should not have worked because the system needs to
create the webadmData attributes and it cannot do it without having
extended the user (with the webadmAccount oclass).

The Error with AD WILL_NOT_PERFORM is certainly because the AD refuses
that WebADM adds the webadmAccount oclass to the user (like in a
2003).

If you raised AD level recently - did your restart the DCs?

[Tom Bean]

Ok, so it turns out even though the schema was upgraded and the Active Directory domain was upgraded, the forest functional level had been left on 2000. Upgrading it to 2008 solved all the issues and it is now working correctly. The process of this was:

1. Opening Active Directory Domains and Trusts

2. Right clicking on Active Directory Domains and trusts in the left hand menu.

3. Select Raise forest functional level.

4. Make sure this is set >2003, if not, upgrade it.