none
Set userAccountControl based on customAttribute

    Question

  • Am I doing this right?

    We need to set the userAccountControl for special user accounts to "user cannot change password" and "Password never expires"...useraccountcontrol bit of 66048.

    If sOACustomAttribute1 is ServiceAccount-Excluded then make useraccountcontrol 66048 else flow normal 512 to useraccountcontrol.

    Here is the flow I'm attempting to use:

    I haven't tried it yet....I was wondering if anyone could let me know if it would work?

    Thursday, March 07, 2013 8:35 PM

Answers

  • Keep in mind that "user cannot change password" is not controlled through the userAccountControl attribute (see http://support.microsoft.com/kb/305144 PASSWD_CANT_CHANGE - The user cannot change the password. This is a permission on the user's object)

    It makes sense to set this service accounts, as you don't want the passwords of these accounts to be changed, on the other hand, what do you want to achieve? That an admin cannot change it? That's done through other permissions. And the only situation where I can see that a service could change it's own password is when the service is "hacked" in someway and the malicious user is doing this to generate a DOS kind of thingy... So you might ask your self, is it worth all the trouble to do this through FIM.

    I agree on the "password never expires" though. Makes sense for service accounts :)


    http://setspn.blogspot.com


    Friday, March 08, 2013 9:26 PM
  • I'm not you need the CopyValue to accomplish this - a better option might be the Code Run activity (if you know C#) to write a few lines of code to return exactly the value you want - and you can send in the value of the sOACustomAttribute1 and return a value. But you would need an extra attribute on users on the Portal, but you could then flow userAccountControl directly (just keep in mind what Thomas writes)

    Regards, Soren Granfeldt
    blog is at http://blog.goverco.com | facebook https://www.facebook.com/TheIdentityManagementExplorer | twitter at https://twitter.com/#!/MrGranfeldt

    • Marked as answer by gdtilghman Sunday, April 28, 2013 6:32 PM
    Sunday, March 17, 2013 7:59 PM

All replies

  • From what you have allowed to met my eyes, it doesn't look that bad :-). Give it a go and test it; thats your best option - it should be pretty straightforward; maybe change that ELSE bit to the number 512 (instead of the test userAccountControl) unless you have an attribute called 'userAccountControl' in the FIM Portal/Service and want to use that value?

    You could create a test Set and MPR to only add this to a few users if you want to do a limited test. 


    Regards, Soren Granfeldt
    blog is at http://blog.goverco.com | facebook https://www.facebook.com/TheIdentityManagementExplorer | twitter at https://twitter.com/#!/MrGranfeldt



    Thursday, March 07, 2013 9:22 PM
  • The only place I could think to put this was in the outbound user synch rule.

    I thought about a workflow based on the set of service accounts I have, but I didn't have a way to flow useraccountcontrol because it's derived in AD.

    If you can come up with a workflow arrangement, i would rather use that because then i would target only those users.

    Thursday, March 07, 2013 9:35 PM
  • Soren....

    Can I use your copy value activity to accomplish this?

    if so, how?  I am having a hard time understanding your examples on codeplex.

    Friday, March 08, 2013 6:53 PM
  • Keep in mind that "user cannot change password" is not controlled through the userAccountControl attribute (see http://support.microsoft.com/kb/305144 PASSWD_CANT_CHANGE - The user cannot change the password. This is a permission on the user's object)

    It makes sense to set this service accounts, as you don't want the passwords of these accounts to be changed, on the other hand, what do you want to achieve? That an admin cannot change it? That's done through other permissions. And the only situation where I can see that a service could change it's own password is when the service is "hacked" in someway and the malicious user is doing this to generate a DOS kind of thingy... So you might ask your self, is it worth all the trouble to do this through FIM.

    I agree on the "password never expires" though. Makes sense for service accounts :)


    http://setspn.blogspot.com


    Friday, March 08, 2013 9:26 PM
  • I'm not you need the CopyValue to accomplish this - a better option might be the Code Run activity (if you know C#) to write a few lines of code to return exactly the value you want - and you can send in the value of the sOACustomAttribute1 and return a value. But you would need an extra attribute on users on the Portal, but you could then flow userAccountControl directly (just keep in mind what Thomas writes)

    Regards, Soren Granfeldt
    blog is at http://blog.goverco.com | facebook https://www.facebook.com/TheIdentityManagementExplorer | twitter at https://twitter.com/#!/MrGranfeldt

    • Marked as answer by gdtilghman Sunday, April 28, 2013 6:32 PM
    Sunday, March 17, 2013 7:59 PM