5

I would like to implement password changing in an organization but they have the domain controller/LDAP passwords "all over the place". They have the passwords in a lot of places, for example, in mobile apps that authenticate against the LDAP, VPN clients, etc.

How to implement a password change policy in this environment? Should the organization first work on reducing or elaborating an inventory of where they have the password introduced?

What if not all passwords can be changed remotely? For example, the organization has the password in mobile apps and may not be possible to access remotely to all the 5000 mobile devices in this organization and change the password. Users may not be prepared to change by themselves the passwords...

Is there any family of solutions or specific UNIX/Windows solutions in order to address this problem?

  • If the password is in a lot of places, it isn't really centralized, is it? Could you change the question to read "decentralized passwords" instead? – ztk Jan 8 '16 at 14:03
  • @ztk The authentication is centralized in a LDAP or Active Directory but that username and password that is in the LDAP and AD should be introduced in different applications that authenticate against the LDAP/AD. So for example, I just have to change the password in one place but then I have to change configurations with that username and password in multiple places. – Eloy Roldán Paredes Jan 8 '16 at 14:49
  • Are you talking about saved passwords needing changing after the central password is reset? Or hard-coded passwords in application code (shudder)? Or something else? Changing the password is easy if the system is truly centralized, it's very unclear what you're asking. – Ben Jan 8 '16 at 15:50
  • I'm talking about passwords in configuration...for example, in an mobile email app you could have your password in the configuration in order to access the email without introducing your password each time. Other example may be a VPN client application in the Windows desktop that have your Active Directory password in the configuration in order to access the VPN without entering the password each time. – Eloy Roldán Paredes Jan 8 '16 at 16:02
2

From the comments, it sounds like the core question is, and please do comment if I'm wrong here: "We have a centralised authentication provider (LDAP) and multiple applications which end users authenticate against this. Is there a way of making it so that if the user changes their password on one of these applications, the change can automatically be applied to other applications, without the user having to update each application individually?"

If that is the case, so that your users can change their password on, say, Outlook, and it automatically updates on their mobile phone, there are some possible methods for doing this, generally involving a password equivalent, such as a verification token. However, it's generally a really bad idea.

Imagine a situation where a user's mobile phone has been stolen. The thief currently has access to their email, and to any email that comes in whilst the same session is active. Given a password reset which requires the updated password to be entered, it's easy to shut off their access to new email - you change the password on the server, and the phone can no longer connect. In your theoretical system, changing the password on the server would not stop the phone from connecting - the password would automatically update.

You may be better off looking at utilising existing functionality in devices to minimise the number of changes that a user will have to perform. For example, Android devices allow for "accounts" which can be used by multiple applications, meaning that if a Google password is updated, it only needs to be entered on the phone once, instead of once per mobile application. Outlook can be configured to allow sign-in using domain login, so that a user who signs into Windows is automatically connected to the Exchange server. In each of these, the password needs to be entered if it is changed, but only once per device.

  • Not exactly but near. Your last paragraph responds to my answer but I would like to know if there are other solutions, for example, SSO and work in integrating every app with the SSO... – Eloy Roldán Paredes Jan 11 '16 at 12:29
  • Your token argument doesn't make a lot of sense to me; the typical token usage I've seen is that the token expires after some time, and you can for the token to expire too. – Andy Aug 19 '18 at 17:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.