No user creation possible after AD Connection

[Former Member]

Hello together,

After my AD Initial Load, User creation with the UI Task "create identity" of the PF is no longer possible.

I get the following great error message:

English:  Task could not be executed

The error message is not very informative.

I have changed the following things on AD initial load:

in the "WriteUserPass"

MSKEYVALUE mapped to sAMAccountNAME

MX_DEPARTMENT mapped to distinguishedNAME

all went well, The users are synced. The distinguishedNAME is added to the Users in IdM.

Is there a way to get a better error message? A log or something?

How can I find out what he needs.

Password provisioning is enabled.

Thank You so much for your reply!!!

[Former Member]

Hi,

If you're having problems with password attributes you should doublecheck that the KEYS.INI file exists and is properly configured in the NetWeaver Admin UI. If this is wrong the Web UI will be unable to encrypt the password you enter when you create the user and thus fails to create the user at all. This will leave you with no logs or messages in the system or job logs. The trace Matt mentions would show the error though.

So,

SAP NetWeaver Administrator

=>Configuration

=>Infrastructure

=>Java System Properties

=>Applications

search for IDM

=>tc~idm~jmx~app

check the com.sap.idm.jmx.cryppt.keyfile property

Best regards,

Per Christian

[former_member2987]

Chris,

Good point, probably also a good idea to make sure that KEYS.INI is consistent on the NetWeaver Server and the place you're doing your work.  Probably not a factor here, but it's a good habit to get into.

Another thought about KEYS.INI... If the NetWeaver Server is on LINUX make sure the rights to the file are properly set (Windows too, but this will happen more often on LINUX)

Matt

[Former Member]

I tried to modify my answer but your reply blocked it 🙂 What I wanted to add is that the only place such an event would be logged is in the NetWeaver developer trace. The runtime trace might not log anything in this situation.

[former_member2987]

Hello Gerhard,

and Former Member are correct, there should be some information in the log, however there's a coupl...

Write a quick script to log the attribute values to the log, just a simple uWarning(Par) will do it from the initial load job.  You can re-use this script for any and all attributes in the pass. You might also want to look at the system log to see if there is any information coming from there.3

You can also try disabling all of the optional attributes (I believe MSKEYVALUE and MX_LASTNAME are required for a MX_PERSON) and then re-enable them one by one until the error occurs.

Finally if you're using IDM 7.2, you can try enabling the TRACE on a test user and execute the process causing the error.  Maybe that will tell you something.

Good Luck!

Matt

[terovirta]

Finally if you're using IDM 7.2, you can try enabling the TRACE on a test user and execute the process causing the error.  Maybe that will tell you something.

Trace is good point. I think the execution won't go that far that any scripts are executed in workflow tasks/passes as it halts with UI input checks. I would still suggest comparing the mandatory attributes from MX_PERSON entry type against the UI task. If for example the AD-account attribute was created for the initial load and has been accidentally set as mandatory.

[Former Member]

Hello togeter,

thank you so much for your answers, You are great.

MX_ENTRYTYPE

DISPLAYNAME

MSKEYVALUE

are mandatory for the Entry Type MX_PERSON

in the UI MSKEYVALUE, MX_FIRSTNAME, MX_LASTNAME, DISPLAYNAME are mandatory.

But I do not think that this is the problem.

If I add a user without a password everything works great. Provisioning in AD and CUA works.

When I try to add MX_PASSWORD to the user i get the message: "Task can not be executed"

I found ou that the IdM installation and the AD domain are different. So I think that's the problem here.

But that he catches this already in the UI, and a commit can not be performed? Is that possible?

BR Gerhard

[former_member2987]

Hi Gerhard,

Are you saying that IDM and AD are on different domains?  Then yes, you need to make sure that the Service Account that is in the AD repository is a member of the correct AD domain, but I don't think that this would cause that message.

Also I just thought of this... Are your password settings correct?  Take a look and make sure that the password policy is correctly defined in the MMC.

Thanks,

Matt

PS -- Good catch on DISPLAYNAME! Not sure how I could have missed that.  Maybe I need coffee!

[Former Member]

Hi Matt,

I suppose exactly the same. Currently I have no policy set in the MMC.

Does the password policy in the MMC need to be more restrictive than AD and CUA?

Or should they be exactly the same everywhere (CUA, AD, MMC)?

Thank You!

[former_member2987]

Hi Gerhard,

It should at least mirror the AD policy.

Standard AD policy is 8 characters and at least two of the three

Capital Letter

Special Character

Number

So that's how you should configure the SAP IDM policy. You might want to do this via a RegEx expression to be safe.  (Not something I can advise on unfortunaltely

Thanks,

Matt

[bxiv]

I believe that is something that can be changed by your AD administrators, verifying with them is what you want to do.

Also I think that standard AD policy you refer to @Matt is for 2008, Server 2003 was fairly lax with the password security.

Another consideration, if you plan on having passwords update and you have the password hook installed to the server; one of the requirements I read about was enabling complex passwords on the domain, which oddly enough was a deal break at my place of employment...

[former_member2987]

Billy, In 2003 this was set via policy.

It is possible to change the AD password policy but it depends on some extra work.

Matt

[bxiv]

You are correct, , that it is done via the domain policy(ies), but by default some features of account policies are not enabled; source: 

http://technet.microsoft.com/en-us/library/cc757692(v=ws.10).aspx#w2k3tr_sepol_accou_set_kuwh

Set Passwords must meet complexity requirements to Enabled.

This tells me that it is either set to not defined or disabled by default and must have admin intervention.  Like most policies I believe it would be not defined.

The best option is to figure out what the domain is currently setup to do, and mimic/duplicate the same within IdM.

[Former Member]

Hi Gerhard

I'd be monumentally surprised if the UI was filtering it based on the fact the AD was a different domain - the UI should have no visibility of it.  It's much more likely to be the password attribute / policy.

Try doing it with a temporary attribute and a subtask that copies the attribute value into MX_PASSWORD.  This should get you some decent errors in the log if nothing else.

Peter

[Former Member]

HI Matt,

Unfortunately it still doesn't work.

Here are the policy settings from AD:

and here the settings in the MMC:

maybe it's really the fact that the IDM and the Active Directory are in different domains?

Thank you for your help!

BR Gerhard

[bxiv]

Doesn't password provisioning also requires that the domain be set to require complex passwords?

[former_member2987]

Billy,

There's no such requirement.  Since the default AD policy in this case is less restrictive than the IDM policy so that will work.  You'll have problems if you try to go the other way.

Figuring out the "lowest common denominator" for password policies is one of the most significant issues that needs to be understood and documented when implementing Password Management.  Note that this is inversely proportional to how much fun it can be.

Matt

[Steffi_Warnecke]

Hello Gerhard,

if you're looking for the log, try the Identity Center Console, where you've changed the pass and created the job for the initial load.

Under "Management" right under your IdCenter configuration you have several logs for your service. I'd say, you should look at the job log and the system log, to get more information of what went wrong.

Regards,

Steffi.

[Former Member]

Hello Steffi,

Unfortunately, there is nothing in, I have already checked all logs in the MMC.

The error occurs in the UI.

Thank You! 

[Steffi_Warnecke]

Hello Gerhard,

even if the error occurs in the UI, it should reflect in the logs there. The UI is just the face, what happens when you start a task, is happening in the background. At least as long it's nothing like "mandatory field isn't filled" or something like that.

If you know, what task should be called, you can look at the logs of that task itself in the provisioning framework. Or is the log queue there empty, too? Can you retry the user creation to see, if the logs show it?

You just want to create an IdM identity, right? Where nothing changed? You just imported the AD informations into IdM and that's it?

Or am I missunderstanding what you're trying to do? ^^

Regards,

Steffi.

[Former Member]

Hi Steffi,

in this case no operations are performed in the MMC.

Even if a mandatory field is not filled by the creation, no logs are shown in the MMC.

But you get an other error massage: "mandatory field not filled".

I think it's the password

If I didn't set a password, it works.

The password policy somehow prevents the user creation.

My current setting:

BR Gerhard

[terovirta]

in this case no operations are performed in the MMC.
Even if a mandatory field is not filled by the creation, no logs are shown in the MMC. 
But you get an other error massage: "mandatory field not filled". 
I think it's the password 
If I didn't set a password, it works.
The password policy somehow prevents the user creation. 

And your UI displays all the mandatory attributes? No new MX_PERSON attributes haven't been made mandatory in the schema?

You would get anything in the logs only after first attempt of running a workflow task (either as linked to your UI or via an event task) after the UI is submitted OK.

Why do you need to have that "enable password provisioning" set? Depends on your sp-level, but the AD password is provisioned automatically if your user has a password in IdM.

[Former Member]

Hello Tero,

It's SP8.

I have "password provisioning" turned on to provision 'the initial password in a CUA.

It works fine before the AD connection. 

Thank You!