启动速达3000服务器时提示SQLSERVER未安装或未设置好登陆账号和密码

启动速达3000服务器时提示SQLSERVER未安装或未设置好登录账号和密码是设置错误造成的，解决方法为：

1、首先要先运行sql server 配置管理器sql server configuration manager。

2、在sql server 配置管理器中找到sql server 服务。

3、启动sql server manager studio 登录服务器。

4、登录成功后,在我们的服务器点右键,找到属性。

5、在打开的属性页面中,找到"安全性"选项卡。

6、在"安全性"选项卡中右侧就可以看到服务器代理账户。

7、选择启用,并填入正确的用户名和密码后，选择右下角的 确定 按钮即可。

1 系统概述
国内领先的支持C－S和B-S架构的单点登录实现机制UTrust SSO（Single sign-on）系统是针对国内企事业信息化发展现状而开发的应用系统管理软件。面对用户的重复登陆，系统管理员繁琐的账号管理工作和系统设置工作，以及如何控制用户的访问权限等问题，UTrust　SSO提供了一个完善的解决方案，在异构的IT系统中实现应用系统单点登录，简化用户的登录过程，同时提供集中和便捷的身份管理、安全的认证机制、权限管理和审计，以满足企业对信息系统使用的方便性和安全管理的需求。
2 系统功能和特点
UTrust SSO单点登录系统提供灵活模块化的解决方案，用户可以将后台应用系统（B/S结构的WEB应用系统和C/S结构的应用系统）和UTrust SSO单点登录系统无缝整合在一起，无须修改原有应用系统，系统主要功能和特点如下：
即插即用方式实现单点登录
对于 B/S结构应用系统，用户只需通过浏览器界面登录一次，即可通过UTrust SSO单点登录系统访问后台的多个用户权限内的Web应用系统，无需逐一输入用户名、密码登录。对于 C/S结构应用系统，通过IE控件来实现对C/S系统客户端的单点登录，用户输入一次用户名、密码，即可访问所有被授权的C/S系统资源。无论对于B/S和C/S结构的应用系统，实现单点登录的功能时，后台应用系统无需任何修改。•后置代理方式实现单点登录 对于有改造条件的B/S结构应用系统，UTrustSSO也提供了后置代理的方式实现单点登录。SSO 系统提供各种API，Agent代理，对原有应用系统进行改造，改变原有应用系统的认证方式，同时采用认证服务器提供的技术进行一次性身份认证，实现单点登录。
后置代理方式实现单点登录
对于有改造条件的B/S结构应用系统，UTrustSSO也提供了后置代理的方式实现单点登录。SSO 系统提供各种API，Agent代理，对原有应用系统进行改造，改变原有应用系统的认证方式，同时采用认证服务器提供的技术进行一次性身份认证，实现单点登录。
与AD域结合单点登录
UTrust　SSO可以与Windows域进行整合，直接引用AD域中的用户身份信息，不需另行单独维护自己的用户信息。当用户登录AD域后，用户无需再登录，就可访问其所有有权限访问的系统，无需再次输入用户名和密码。
统一用户身份管理
UTrust SSO 利用账号同步管理模块，将用户的身份信息和密码同步到各个系统的数据库中，系统管理员在一个平台上统一管理用户在各个系统中的账号和密码。在人员离职、岗位变动时，只需在UTrust SSO管理中心一处更改，即可限制其访问权限，消除对后台系统非法访问的威胁。方便了用户管理，也防止过期的用户身份信息未及时删除给企业资产带来的安全风险。
统一身份认证
UTrust SSO采用轻量目录存取服务LDAP来建构统一用户信息数据库。LDAP作为一个公开和开放的目录服务标准，已成为未来身份认证和身份管理的标准，具有很好的互 *** 作性和兼容性，可以为企业搭建一个统一身份认证和管理框架，UTrust SSO系统提供开发接口给新建系统，可为后续新的应用系统开发提供了统一的身份认证平台和标准。
多种身份认证方式
UTrust SSO支持多种身份认证方式，如数字证书，USB Key，动态口令身份认证，同时也保留了传统的静态口令认证，并且为其他认证方式如短信，生物特征等认证方式预留接口，以适应企业对认证方式扩展的需求。
日志和审计报告
UTrust SSO单点登录系统依靠记录最终用户和管理人员的访问过程，建立一套全面的、有效的回溯和追查机制。同时系统管理员可以实时监测用户对企业各应用系统的访问状态，及时发现非法访问事件，对出现的问题进行事后追溯和责任追究提供实证。通过对系统运行状态实时监控审计，还增强了系统的可维护性。主要完成访问行为审计、审计信息查询、审计信息防窜改和黑名单功能等几大功能。
系统集中管理
UTrust安全管理中心为UTrust单点登录系统提供管理功能，实现对用户身份信息，权限，应用系统，审计信息的集中管理。UTrust安全管理中心基于Web界面，系统管理员通过这个管理中心可对用户，资源，权限及审计信息进行统一的管理，并对UTrust系统本身进行维护管理。同时系统支持分级授权管理功能，支持总部授权下属单位管理自身的用户，并对其授权，减少总部管理员的负担。
即插即用和灵活部署
UTrust SSO单点登录系统进行安装或方案实施时，只需经过简单的系统配置，即可使用。对于分布式网络结构和异构系统，可以在不同网络区域的应用服务器上分布式的部署UTrust SSO单点登录系统，并进行系统集群管理，通过集群功能，提高数据通讯时的负载均衡和并发处理能力，得到安全可靠和高效的单点登录服务。此外，还可以通过双机备份功能，提高整个系统的安全性。
3 系统环境
客户端支持的 *** 作系统：
Windows98/NT/2000/XP
服务器端支持的 *** 作系统：
Windows NT/2000、Unix(HP-UX、Solaris、AIX)、Linux、FreeBSD
数据库：
Oracle、SQL Server或My SQL等关系型数据库
目录服务器：
标准的LDAP目录服务器

一般情况下，当用户登录一个站点后，如果长时间没有任何动作，当用户再次单击时，会被强制登出并跳转到登录页面，提醒用户重新登录。

现在我已经为站点整合了CAS，并且已经实现了单点登录以及单点注销，那么当用户使用过程中，发生了超时的情况，估计也是自动强行登出了吧，而且其他部署了CAS的站点也跟着自动登出。
上面的是猜想，那么实际情况到底是什么样的？

CAS-Client客户端超时时间其实就是项目session的有效时间，默认：30分钟，（springboot2x）可修改配置：

验证方法：

a 事前准备：

b 验证动作：

2分钟后，我优先单击webApp1的网页，仿佛没有发生任何与超时相关的处理，依然可以正常访问所有页面。并没有强制跳转到登录页。我再单击webApp2的网页，也可以正常浏览。
又过了2分钟，我优先单击webApp2的网页，可以正常访问。再此单击webApp1，也可以正常访问。

c 验证结果：

cas服务器超时主要指的是TGT（ticket granting ticket）超时，如果TGT时间到期，则需要进行重新登录。默认是2小时。这里单位是秒

验证方法：

a 事前准备：

b 验证动作：

3分钟后，CAS-Server应该已经超时了，这时我访问webApp1，可以正常访问。访问webApp2，也可以正常访问。

6分钟后，CAS-server与webApp1应该都超时了，这时访问webApp1，页面被强制重定向到登录页面了。再访问webApp2，发现仍然可以正常访问。

11分钟后，webApp2页超时了，这时访问webApp2，页面就被重定向到登录页面了。

c 验证结果：

3一个客户端超时并不会影响其他客户端的正常访问。

从上面两个验证可以发现，一旦客户端通过CAS-Server认证后，客户端就相当于完全独立了，即使再访问客户端的页面，客户端与CAS-Server之间也不会再发生任何交互或者验证动作。
一直到客户端强制退出或者超时后，才会主动发起认证请求，CAS-Server才会被动处理请求，判断是需要重定向还是重新认证通过。

也就是说，如果服务器超时时间设置的过短，并不会起作用，还是要等客户端超时才行。

鉴于以上结论，客户端和服务器的超时时间设置应该为：
CAS-Server（TGT）超时时间 >= CAS-Client的超时时间

从之前的验证来看，一个站点超时，并不影响其他站点的正常访问。

CAS-Server和CAS-Client超时结果图：

代码不能帖给你 不好意思
使用 CAS-server组件 一般的,单点登录都是使用LDAP数据库
我之前给学校做过一个基于SOA的校园统一管理构建 使用的就是这套配置 不错呀不错 呵呵~~
单点登录的重点是:无论两个网站地域和服务器是否分离,只要他们服务器上面都有你单点登录服务器上的证书存根即可 所以不需要关心什么域名之类的东西 只要证书存根在每个网站上 一切好说
你的思路有些问题:单点登录并不是对网站cookies的传递 它是基于>一、简单例子
在讲单点登录之前，我们讲一些客户端是如何跟服务器交互的。举微信为例子，我们手机登录了微信，此时服务器就会返回一把钥匙（token）给APP，这把钥匙就是证明我是谁？例如我是Candy，每次都拿这把钥匙去请求服务器，例如获取Candy的朋友圈数据，Candy的微信好友列表等，当我们退出登录的时候，我们会告诉微信说钥匙过期啦。

好，这里我们要记住，登录微信，获取微信给我们的钥匙，用钥匙去拿对应数据。当我们退出微信的时候，我们会告诉微信说钥匙

二、概念讲解
进入主题，单点登录SSO，英文是Single Sign On。那什么是单点登录呢？
你有两个手机，一个登陆了微信，另一个只要点击登录微信，前一个手机就会推出微信，这个就是单点登录。
那多点登录呢？你想想你的iPad，或者是电脑，是不是都可以同时登陆微信？这个就是多点登录，
那他的原理是什么？还是那把钥匙，只是微信给了他们iPad跟手机一把强关联的钥匙，手机也好，iPad也好，都可以用这把钥匙，拿到他们对应的数据。

三、思维拓展
例子：为什么说是强关联呢？还是举微信手机的例子，
1、从主次来讲，我们先区分手机，电脑，iPad的钥匙主次，当电脑登录微信的时候，手机能否把电脑的微信退出？答案是可以。我们手机可以控制电脑的微信锁定，甚至是退出。这里的钥匙主次是以手机为主，但这不是唯一的答案，这是产品设计的，只要产品愿意，程序员也是可以把电脑的主权上升的，电脑也可以让手机退出，关键在于电脑登录微信是通过手机扫码的，所以手机的钥匙肯定是占据主动的，这样比较符合产品设计。
2、还是刚刚那样的例子，手机A已经登录了微信，甚至也登录了电脑微信，此时手机B登录微信，会怎么样？手机A会退出微信，同时手机A登录的电脑微信也会退出。为什么？这就是那把钥匙被退出的原因。

总结一下这节课，这节课最重要的概念是，手机登录，服务器给钥匙，这把钥匙就是证明你是谁，每次访问服务器，都会根据这把钥匙是谁，而给出对应的数据，如candy的朋友圈，candy的好友列表等。

四、程序优化，架构优化。
关于架构优化的知识点。
举个例子，某电商公司A收购了物流公司B，我们用户在电商APP登录的时候，需要先登录电商系统A，获得了电商钥匙A，然后用电商钥匙A，去物流系统B拿物流钥匙B，这一步用了两个步骤，那当出现系统3，系统4的时候，我们的步骤会非常的多，所以我们可以在多个服务中建立SSO系统（单点登录系统），所有系统，电商系统A，物流系统B，房地产系统C…全都去那里登录，统一一把钥匙访问所有功能系统。

你可以试一下用一个服务器，放登录的令牌。

用户调用客户端时，去服务器上验证用户的令牌。

还有一种模拟用户键盘 *** 作，输入用户名密码。但是这种方法受到客户端设置限制，不是100%可靠。

昨天碰到了一篇讲单点登录（SSO）的文章，作者可能是从字面意思理解的单点登录（只允许一个地方登录，一方登陆了，另一方就要下线，这种应该是单设备登录）。正好最近我也在处理多系统访问的问题，也要用到单点登录，就打算整理点东西。

单点登录： 英文Single Sign On，根据英文含义不难理解，即：单一标记（单点）登录。就是说，我只需要登录一次。例如：QQ，我在QQ空间登录一次，我可以去访问QQ产品的其他服务：QQ邮箱、腾讯新闻等，都能保证你的账户保持登录状态。

单设备登录： 就是只能在一个设备上登录，若同时在其他设备登录，先前登录的用户会被提醒：该账户在其他设备登录。例如qq，小米手机登录中，同时拿华为手机登录该账户，小米手机的账户会被挤下线。

SSO（Single Sign-On）是一种统一认证和授权机制，指访问同一服务器不同应用中的受保护资源的同一用户，只需要登录一次，即通过一个应用中的安全验证后，再访问其他应用中的受保护资源时，不再需要重新登录验证。

解决了用户只需要登录一次就可以访问所有相互信任的应用系统，而不用重复登录。

如下图所示：

当用户第一次访问应用系统1的时候，因为还没有登录，会被引导到认证系统中进行登录；根据用户提供的登录信息，认证系统进行身份效验，如果通过效验，应该返回给用户一个认证的凭据－－ticket；用户再访问别的应用的时候，就会将这个ticket带上，作为自己认证的凭据，应用系统接受到请求之后会把ticket送到认证系统进行效验，检查ticket的合法性（4,6）。如果通过效验，用户就可以在不用再次登录的情况下访问应用系统2和应用系统3了。

从上图可以看出sso的实现技术点：

1）所有应用系统共享 一个身份认证系统 。

统一的认证系统是SSO的前提之一。

认证系统的主要功能是将用户的登录信息和用户信息库相比较，对用户进行登录认证；认证成功后，认证系统应该生成统一的认证标志（ticket），返还给用户。

另外，认证系统还应该对ticket进行效验，判断其有效性。

2）所有应用系统能够识别和提取ticket信息

要实现SSO的功能，让用户只登录一次，就必须让应用系统能够识别已经登录过的用户。

应用系统应该能对ticket进行识别和提取，通过与认证系统的通讯，能自动判断当前用户是否登录过，从而完成单点登录的功能。

关于 统一身份认证机制 ：如下图

①用户请求访问业务系统。

②业务系统在系统中查看是否有对应请求的有效令牌，若有，则读取对应的身份信息，允许其访问；若没有或令牌无效，则把用户重定向到统一身份认证平台，并携带业务系统地址，进入第③步。

③在统一身份认证平台提供的页面中，用户输入身份凭证信息，平台验证此身份凭证信息，若有效，则生成一个有效的令牌给用户，进入第④步；若无效，则继续进行认证，直到认证成功或退出为止。

④用户携带第③步获取的令牌，再次访问业务系统。

⑤业务系统获取用户携带的令牌，提交到认证平台进行有效性检查和身份信息获取。

⑥若令牌通过有效性检查，则认证平台会把令牌对应的用户身份信息返回给业务系统，业务系统把身份信息和有效令牌写入会话状态中，允许用户以此身份信息进行业务系统的各种 *** 作；若令牌未通过有效性检查，则会再次重定向到认证平台，返回第③步。

1）提高用户的效率。

用户不再被多次登录困扰，也不需要记住多个 ID 和密码。另外，用户忘记密码并求助于支持人员的情况也会减少。

2）提高开发人员的效率。

SSO 为开发人员提供了一个通用的身份验证框架。

实际上，如果 SSO 机制是独立的，那么开发人员就完全不需要为身份验证 *** 心。

他们可以假设，只要对应用程序的请求附带一个用户名，身份验证就已经完成了。

3）简化管理。

如果应用程序加入了单点登录协议，管理用户帐号的负担就会减轻。

简化的程度取决于应用程序，因为 SSO 只处理身份验证。

所以，应用程序可能仍然需要设置用户的属性（比如访问特权）。

1）不利于重构

因为涉及到的系统很多，要重构必须要兼容所有的系统，可能很耗时

2） 无人看守桌面

因为只需要登录一次，所有的授权的应用系统都可以访问，可能导致一些很重要的信息泄露。

---