如何在不同场景下采用正确的重置密码和解锁方式?

就像大家知道的,ADSelfService Plus 允许员工重置忘记的密码,并且解锁自己的账户。这些功能深受大家欢迎,非常多的企业已经采取了这种模式,让员工自己去重置自己的密码、解锁他们的账户。我们要做的就是确保所有使用ADSelfService Plus的用户可以完全掌握该软件的各个功能,并能够熟练的进行操作。下面我们来讲解重置密码以及解锁账户的三种方式:

  1. 使用iPhone或者安卓手机应用程序来实现, 如图1所示。移动应用程序可以从App Store或Play Store下载。
    图1. ADSelfService Plus 手机应用界面

  1. ADSelfService Plus通过电脑联网,门户登录账户方式实现。这不是最理想的解决方案,但它却是非常常见的使用方式。用户可以快速访问ADSelfService Plue门户,http://servername:8888,无需访问计算机上的任何应用程序或文件,这就提供了一个快速和安全的解决方案。如图2所示门户登录

图2.?ADSelfService?Plus 浏览器登录门户

从用户的登录屏幕进行重置密码和解锁账户,如图3所示。GINA是由ADSelfService设计和开发的。GINA允许用户轻松地重置自己的密码或解锁自己帐户,而不需要使用任何其他设备。

图 3.?ADSelfService?Plus?GINA
对于远程雇员,同样可以使用ADSelfService Plus重置密码和解锁用户帐户。这种情况,因为雇员不在公司网络里,问题就变得复杂了。ADSelfService Plus手机应用软件可以重置密码。但是,需要修改GINA配置和门户选项,以便允许访问ADSelfService Plus服务器。 由于GINA更和门户选项是基于HTTP的,URL可以修改,使其通过Internet连接到网络。要查看这些选项具体信息,请参考文档。
现在,您就有了合适的解决方案:雇员使用ADSelfService?Plus重置密码或解锁账户。如果你现在没有ADSelfService Plus,可以点击这里下载。

原文地址:http://blog.51cto.com/13802097/2144382

时间: 2024-10-09 03:42:04

如何在不同场景下采用正确的重置密码和解锁方式?的相关文章

[原]不同场景下MySQL的迁移方案

一 为什么要迁移 MySQL 迁移是 DBA 日常维护中的一个工作.迁移,究其本义,无非是把实际存在的物体挪走,保证该物体的完整性以及延续性.就像柔软的沙滩上,两个天真无邪的小孩,把一堆沙子挪向其他地方,铸就内心神往的城堡. 生产环境中,有以下情况需要做迁移工作,如下: 1.磁盘空间不够.比如一些老项目,选用的机型并不一定适用于数据库.随着时间的推移,硬盘很有可能出现短缺: 2.业务出现瓶颈.比如项目中采用单机承担所有的读写业务,业务压力增大,不堪重负.如果 IO 压力在可接受的范围,会采用读写

不同场景下 MySQL 的迁移方案

不同场景下 MySQL 的迁移方案 Posted in MySQL and tagged MySQL, 数据迁移, 方案 on Sep 15, 2015. Viewd 2684 times. 文/温国兵 一 目录 一 目录 二 为什么要迁移 三 MySQL 迁移方案概览 四 MySQL 迁移实战 4.1 场景一 一主一从结构迁移从库 4.2 场景二 一主一从结构迁移指定库 4.3 场景三 一主一从结构双边迁移指定库 4.4 场景四 一主一从结构完整迁移主从 4.5 场景五 双主结构跨机房迁移 4

缓存在高并发场景下的常见问题

缓存一致性问题 当数据时效性要求很高时,需要保证缓存中的数据与数据库中的保持一致,而且需要保证缓存节点和副本中的数据也保持一致,不能出现差异现象.这就比较依赖缓存的过期和更新策略.一般会在数据发生更改的时,主动更新缓存中的数据或者移除对应的缓存. 缓存并发问题 缓存过期后将尝试从后端数据库获取数据,这是一个看似合理的流程.但是,在高并发场景下,有可能多个请求并发的去从数据库获取数据,对后端数据库造成极大的冲击,甚至导致 “雪崩”现象.此外,当某个缓存key在被更新时,同时也可能被大量请求在获取,

多线程场景下延迟初始化的策略

1.什么是延迟初始化 延迟初始化(lazy initialization,即懒加载)是延迟到需要域的值时才将它初始化的行为.如果永远不需要这个值,这个域就永远不会被初始化.这种方法既静态域,也适用于实例域. 最好建议“除非绝对必要,否则就不要这么做”. 2.延迟初始化线程安全的一个策略:同步 延迟初始化的一个好处,是当域只在类的实例部分被访问,并且初始化这个域的开销很高,那就可能值得进行延迟初始化. 但是在大多数情况下,正常的初始化要优先于延迟初始化.因为在多线程的场景下,采用某种形式的同步是很

[转]Net 下采用GET/POST/SOAP方式动态调用WebService C#实现

本文转自:http://www.cnblogs.com/splendidme/archive/2011/10/05/2199501.html 一直以来,我们都为动态调用WebService方法而烦恼.在.Net环境下,最常用的方法就是采用代理类来调用WebService,可以通过改变代理类的Url属性来实现动态调用,但当xmlns改变时就会出错,似乎要重新绑定Webservice并重新编译后才能再次运行.我无意中通过百度搜索找了一个采用GET/POST/SOAP方式动态调用WebService的

互联网业务场景下消息队列架构

消息队列作为一种基础的抽象数据结构,被广泛应用在各类编程与系统设计中. 同步VS异步 通信的一个基本问题是:发出去的消息什么时候需要被接收到?这个问题引出了两个基础概念:"同步通信"和"异步通信".根据理论抽象模型,同步通信和异步通信最本质的差别来自于时钟机制的有无.同步通信的双方需要一个校准的时钟,异步通信的双方不需要时钟.现实的情况是,没有完全校准的时钟,所以没有绝对的同步通信.同样,绝对异步通信意味着无法控制一个发出去的消息被接收到的时间点,无期限的等待一个消

Netty实践(三):实际场景下的数据通信

数据通信的场景:长连接 OR 短连接 在实际场景中,我们如何使用Netty进行通信呢?大致有3种方式: 第一种,使用长连接通道不断开的形式进行通信,也就是服务器和客户端的通道一直处于开启的状态.如果服务器性能足够好,并且我们的客户端数量也比较少的情况下,是适合使用长连接的通道. 第二种,采用短连接方式,一次性批量提交数据,也就是我们会把数据保存在本地临时缓冲区或者临时表里.当达到数量时,就进行批量提交:或者通过定时任务轮询提交.这种情况是有弊端的,就是无法做到实时传输.如果应用程序对实时性要求不

asp.net core中负载均衡场景下http重定向https的问题

上周欣喜地发现,微软官方终于针对 asp.net core 在使用负载均衡的情况下从 http 强制重定向至 https 的问题提供了解决方法. app.UseForwardedHeaders(new ForwardedHeadersOptions { ForwardedHeaders = ForwardedHeaders.XForwardedProto }); var options = new RewriteOptions() .AddRedirectToHttpsPermanent();

秒杀场景下MySQL的低效(转)

秒杀场景下MySQL的低效 2016-01-14 17:12 178人阅读 评论(0) 收藏 举报 最近业务试水电商,接了一个秒杀的活.之前经常看到淘宝的同行们讨论秒杀,讨论电商,这次终于轮到我们自己理论结合实际一次了. ps:进入正文前先说一点个人感受,之前看淘宝的ppt感觉都懂了,等到自己出解决方案的时候发现还是有很多想不到的地方其实都没懂,再次验证了"细节是魔鬼"的理论.并且一个人的能力有限,只有大家一起讨论才能想的更周全,更细致.好了,闲话少说,下面进入正文. 一.秒杀带来了什