Workflow and ServiceDesk Community

We are trying to create a user in AD with a process and when it runs I get the following error

The (&(objectClass=user)(name=)) search filter is invalid.

My guess is that the filter above requires some sort of search value, like (&(objectClass=user)(name=*)) (note the included *... that filter should briing back any user)

I got around the above error my common name was messed up. But now I am getting this:

Exception has been thrown by the target of an invocation.

The account still creates but for some reason it auto disables and auto flags user must change password at first login.

Any thoughts on any of the above issues?

Thanks 

Can you force the value of Must Change PW at Next Login to false and set Enabled to true?

I have found the exception error happens if I re run the process to fast. If I give it a few min and run it again works fine.

I my Dyanamic value that I used for mapping my AD to my process

I have AccountISDisabled set to False  and Usermustchange password is false

but it still doesnt handle it correctly.

Here is the Exception being thrown when we get that error:

Its weird it is a access denied error but it works every now and then so I am not sure why if you go back to back it errors with access denied.

It looks like access denied is getting thrown after setting the password. I'd verify that whatever user you're using to connect to AD has rights to update passwords in whatever group/OU the user is getting created in.

The account we setup in the Project properties can update that OU no problem its a domain admin account that I am using for testing.

Also as I said if I wait upwards of 10 min to run the process again it will create the user. Its almost like it doesnt like that attempt by the domain account to hit the AD twice.

I have found the error was a result of having a password field mapped to a field we have called password. It was erroring. Now the question is how can you use workflow to set the password in AD. I have tried the reset password component and it errors with the same error.

After some digging I have found the permission error when trying to force a password was a result of the application pool.  The app pool has to be setup to run as a domain admin to run the password functions from workflow. This is a major secuirity hole since how are people getting around this or do they just not care?

Thanks 

I haven't verified this, but I'm guessing that it's not that the app pool needs to run as a domain admin. I bet you could create an account for this purpose and grant it only the rights it actually needs, rather than full control of the domain. We have a couple workflows setup in a similar fashion, but they aren't performing the exact same tasks as yours.

Michael thanks for the info, I am not 100% sure but when we swtitched from the default app pool running as a network service a test one running a domain admin account the password reset worked perfect.  

Also to verify the Debut of the reset works as well which as far as I know runs as the user logged in which is a domain admin account as well.

thoughts?

Yes, that's how the debug mode works. Yes, I'm sure that it went fine with a domain admin as the app pool ID. What I'm suggesting is that instead of a domain admin, use a service account that only has the permissions you need, not all permissions. Yes, you are exposing security a bit, but by limiting the permissions, you limit your exposure.

That was what I trying just created a quick AD user gave it the AD delegate permissions it needed. Then assigned the user to the APP pool started the app pool now my Page errors every time unless I sit in the default pool. Some times I really do hate windows :)

Ugh. Darn windows IIS service nonsense.

Maybe #2 from here: http://stackoverflow.com/questions/178633/minimum-rights-required-to-run-a-windows-service-as-a-domain-account

Thanks for your help but I am about ready to give up on this stupid thing. I have the Apppool starting now with a AD user. Site loads fine get to where it wants to change the password and then it blows up again with the failure notice due to AD permisisons even though the user has full control over AD right now as a test. 

I can't give any specific advice on troubleshooting that issue, but I am a firm believer in pounding your head against the wall until it breaks. The wall, not your head, that is. Hang in there and post back when you get it sorted.

Thanks for the help. I have moved on and will look at it again in new light later. I am sure it is a simple check mark somewhere that is the issue it always seems to be that way. :)

Dkromm,

I have a couple workflows who create and manipulate AD objects like users,computers,groups etc.

There are a  couple things you have to set:

• create a kerberos authentication token with enough AD rights to manipulate AD objects (picture1)
• User the create user component and under context be zure you input the correct settings (picture2)
• In the User info From Variable there are a few mapping/entries you MUST enter, otherwise the user will not get created (picture3) These settings are mandatory by MS but are not shown as mandatory in the component. The error you recieve in the debug log do not show a correct error description, so you sadly enough will not immediatly know why :-(
• In the project properties set the authentication to Windows Authentication if you want to work with security and AD (I usely do so)
• In the Resources tab you can edit the web.config file and check if the header Authentication mode is set to Windows, otherwise you can change it to Windows without any problems
• In the IIS I recommend that you create per sort of workflowapps a new APP pool with the appropiate rights and set it to Classic mode
• In the advanced settings you can then add a domain user (he does not have to have admin rights because the admin user is set in the workflow project, just a domain user is enough) (picture4)

I hope you can work with this info, otherwise do no hesitate to let me know if something does not work :-)

Asnotb:

Thanks for the info it put me on the right path but I dont think it was 100% my issue this is what I have found.

I am using the get current user component to pull in my managers name(User running the process). To do this ASP.Net impersonation needs to be turned on. If ASP.Net impersonation is turned on when I try and write passwords to AD it errors even with the kerobos token. If i shut of ASP.net impersonation I can write to AD just fine. 

I can create users in AD just fine, I just can't update the passwords or change the user must change password at next login flag.

Any idea how to get around this? 

we just built a second process fo the AD part that doesnt need the ASP.Net as it is only our IT staff that run it seems to be the best fit for us.