password-change in AD pickup by SL only after restart

[jpardol]

We will not be able to pass the details of NSL to AD, due to the complexity to be here 3 different domains so that the scheme would have to stretch out in all three.

¿NSL does not have any configuration or workaround for this type of password changes? I do not know any way to put some delay when there has been a change of password, or something similar?

I think that something as common and is typically done on all companies at least once a month, should be covered by an SSO solution.

So adding the NSL details to AD would ensure that the Windows change is
always caught and passed to NSL. The issue there is gfetting all of the
details in to AD first. Always a challenge.

Dave

jpardol wrote:
> - Then, in our scenario (a) When the user change his password by
> pressing Ctrl + Alt + Del, I always will have to enter the new password
> in NSL?
>
> - In our scenario (b) the problem is when the change password finished
> in AD, and in edir it haven't finished it. I found other post In which
> talk about having only one driver for AD password change and reduce the
> time it takes to produce change.
>
>
> If instead of having the credentials of NSL in edir, we had in AD these
> circumstances would be eliminated? I understand that all information
> being in AD might not have any problem changing the password in AD.
>
>
> David Guest;1866061 Wrote:
>> Your scanario a should work the way you want. Ideally they should be
>> changing both the AD and Novell passwords from this screen so that NSL
>> does not care and sees the change locally. This is what it is
>> designed
>> to do.
>>
>> With the change coming from AD NSL sees the change and repudiates it
>> as
>> it has no knowledge of the change. You need to then put in the old
>> password to "unlock" the store. This is because of the password
>> inclusion as part of the encryption.
>>
>> Dave
>>
>> jpardol wrote:
>>> We synchronize passwords, when performing a password change from MS
>> AD.
>>> The passwords are synchronized in AD, edir, and various systems
>> more.
>>> We have two scenarios:
>>>
>>> a) If you change the password by pressing control + alt + sup, when
>> the
>>> user is already logged on the MS network then the password is
>>> automatically synchronized (connectors in IDM). BUT NSL ask the
>> password
>>> when the cache expires and tries to connect to Edir becuase then the
>>> password in the Edir there isn't the same as the password to access
>> the
>>> system. And once we put the new password, and works ok.
>>>
>>> b) If you change the password when the user is not logged on the
>>> network "PASSWORD EXPIRED" or "User must chnage password at next
>> logon"
>>> then the password is automatically synchronized (IDM connectors).
>> But
>>> the user is validated on the network, before it has synchronized the
>>> edir password and then NSL requests the password. And therefore,
>> until
>>> the password synchronization process doesnt end, we cant access to
>> NSL
>>> with the new password .
>>>
>>> Is there any way we can solve:
>>>
>>> - That on scenario a) DONT request the new password when you made a
>>> password change in MS AD.
>>> - That on scenario b) NSL somehow expect when you have made a
>> password
>>> change in AD (although it be through some kind of delay)
>>>
>>> David Guest;1865218 Wrote:
>>>> If you change the password with the MS Gina which is what this
>> sounds
>>>> like the password will not be linked to the Novell Client. This
>> means
>>>> that the password will not pass through although this could be done
>>>> with
>>>> Identity Management. If the user changes the password throught the
>>>> Novell GINA and leaves the MS link enabled both passwords will
>> change.
>>>> Dave
>>>>
>>>> jpardol wrote:
>>>>> Do you solved this issue? We have version 6.1.0.014 and when we
>> make
>>>> a
>>>>> change of password when the password expires or "user must change
>>>>> password at next logon, the password change is done in Windows and
>>>> when
>>>>> you try to validate Secure Login password change has not spread to
>>>>> eDirectory.
>>>>>
>>>>>
>>>
>
>