SAP用户权限管理配置及操作手册SAP用户权限管理配置及操作手册SAP用户权限管理配置及操作手册Overview业务说明OverviewSAP的每个用户能够拥有的角色是有数量限制的，大概是300多点，具体不记得了。
如果只在S_TCODE和菜单中设置了某个事务代码，而没有设置权限对象，此时将不能真正拥有执行该事务代码的权限。
SAP的权限检查机制：SAP进入一个t-code，要检查两个东西1）S_TCODE2) 表TSTCA 里面和这个T-cdoe相对应的object。
有些tcode在tstca里面没有对应的object，就会导致直接往S_TCODE中加事务代码不能使用的情况。
SAP权限架构概念权限对象Authorization objectSAP在事务码（T-code）的基础上通过权限对象对权限进行进一步的细分，例如用户有创建供应商的权限，但是创建供应商的事务码中有单独的权限对象，那么就可以通过权限对象设置不同的用户可以操作不同的供应商数据。
角色-Role同类的USER使用SAP的目的和常用的功能都是类似的﹐例如业务一定需要用到开S/O的权限。
当我们把某类USER需要的权限都归到一个集合中﹐这个集合就是“职能”(Role)。
所谓的“角色”或者“职能”﹐是sap4.0才开始有的概念﹐其实就是对user的需求进行归类﹐使权限的设定更方便。
(面向对象的权限!!)分为single role 和composite role两种﹐后者其实是前者的集合。
角色模板-Template RoleRole的模板﹐一般是single role.但这个模板具有一个强大的功能﹐能通过更改模板而更改所有应用(sap称为Derive“继承”）此模板的Role(sap称之为adjust)参数文件-Profile参数文件相当于指定对应的权限数据及权限组的定义。
每个角色下会产生一个附属的参数文件。
真正记录权限的设定的文件﹐从sap4.0开始是与Role绑定在一起的。
虽然在sap4.6c还可以单独存在﹐但按sap的行为推测﹐以后将不能“一个人活着”用户-User就是通常说的账号（User ID）。
通常的用户类型有a.dialog (就是正常的用户)municationc.systemd.servicee.reference.TableNo. Table name Short Description MemoUSR01 User master record (runtime data)USR02 Logon Data (Kernel-Side Use) 用户的登录信息USR03 User address dataUSR05 User Master Parameter IDUSR06 Additional Data per UserUSR07 Object/values of last authorization check that failedUSR08 Table for user menu entriesUSR09 Entries for user menus (work areas)USR10 User master authorization profilesUSR11 User Master Texts for Profiles (USR10)USR12 User master authorization valuesUSR13 Short Texts for AuthorizationsUSR14 Surchargeable Language Versions per UserUSR15 External User NameUSR16 Values for Variables for User AuthorizationsUSR20 rate of last user master reorganizationUSR21 Assign user name address keyUSR22 Logon data without kernel accessUSR30 Additional Information for User MenuUSR40 Table for illegal passwordsUSR41 User master: Additional data 每个用户当前的登录信息USREFUSUSRBF2USRBF3UST04 User masters 定义每个用户对应的ProfileUST10C Composite profilesUST10S Single profiles (角色对应的UST12 AuthorizationsSUKRI Transaction Combinations Critical for Security TOBJ Authorization Objects 所有的权限对象Configure角色配置相关事务码PFAC 维护规则PFAC_CHG 改变PFAC_DEL 删除PFAC_DIS 显示PFAC_INS 新建PFAC_STRPFCG 创建ROLE_CMP 比较和调整角色SUPC 批量建立角色profile SWUJ 测试SU03 检测authorzation dataSU25, SU26 检查updated profile SU24 查看事务代码的权限对象。
用户维护相关事务码SU0 维护用户参数SU01维护用户SU01D显示用户SU01_NAVSU05SU50, Su51, SU52SU1SU10 批量SUCOMP:维护用户公司地址SU2 change用户参数SUIM 用户信息系统。
是一组菜单，可以进行常用的用户及权限管理。
SUGR:维护用户组SUGRD:显示用户组SUGRD_NAV:显示用户组SUGR_NAV:维护用户组Profile&Authoraztion DataSU02:直接创建profile不用roleSU20:细分Authorization FieldsSU21(SU03):维护Authorization Objects(表TOBJ,USR12).对具体transaction code细分:SU22 维护权限对象的分配关系SU24 维护权限对象的分配关系SU53:检查用户当前的权限，例如可以检查没有哪些权限对象。
SU56:分析authoraztion data buffers.SU87:用来检查用户改变产生的historySU96,SU97,SU98,SU99:干啥的?SUPC:批量产生role会计凭证的权限对象会计凭证包含以下权限对象：F_BKPF_BED: Accounting Document: Account Authorization for Customers F_BKPF_BEK: Accounting Document: Account Authorization for VendorsF_BKPF_BES: Accounting Document: Account Authorization for G/L AccountsF_BKPF_BLA: Accounting Document: Authorization for Document TypesF_BKPF_BUK: Accounting Document: Authorization for Company CodesF_BKPF_BUP: Accounting Document: Authorization for Posting PeriodsF_BKPF_GSB: Accounting Document: Authorization for Business AreasF_BKPF_KOA: Accounting Document: Authorization for Account TypesF_BKPF_VW : Accounting Document: Change Default Values for Doc.Type/PsKy可以通过USR12表查询. 在DB层是UTAB.创建角色PFCG需要先确定是创建普通角色还是组件角色。
对于组件角色是指可以包含其他的角色，相当于一个角色组，可以实际对应一些岗位，而将角色进行原子化。
执行“创建角色”。
如果希望继承其他的折旧，可以将父角色的编码填入“Derive from Role”字段中，在父角色改变后，需要在角色修改时，在权限的授权数据中，执行权限菜单中的“调整派生”功能。
在做下一步之前，需要先保存。
增加文件夹，同时在文件夹下插入事务码。
切换到权限页标签。
执行参数文件旁的按钮“Propose Profile Names”，生成参数文件的名称。
保存后，执行“Change Authorization Data”。
设置“Authorization Group”为genl。
其他相关的权限全部设置为“*-所有”最后生成一次，执行“Generate“。
角色的请求传输角色不会自动记录到请求，必须手工执行一个传输的动作。
产生的是一个Customizing request。
创建用户SU01设置用户的类型。
对于一般用户都设置为”A Dialog”。
切换到角色页标签。
可以设置刚才创建的角色，同时可以指定有效日期。
最后保存即可。
受限用户的登录使用创建的受限用户登录后，将受限显示用户菜单，也就是在角色中创建的用户菜单。
每个角色的菜单将会并排显示，所以如果希望显示成一个文件夹，就需要使用一个角色，或者通过修改标准的菜单结构来实现。
创建供应商-GENL权限组FK01创建供应商-非GENL权限组FK01公司代码层的权限组暂时不设置，这样所有用户都可以进行操作。
受限用户修改供应商测试-genl权限组FK02受限用户修改供应商测试-非GENL权限组如果受限用户希望显示未授权的供应商也是同样的结果。
FK02系统会提示一般没有对一般数据层的修改权限。
受限用户创建供应商测试-非GENL权限组FK01保存时，系统会给出错误提示信息。
为角色增加用户我们新建一个角色。
直接指定用户后，系统显示还是红灯。
需要执行“User Comparison“。
执行完成后，角色的状态才会变绿。
重新使用受限用户登录可以发现两个角色的菜单直接叠加了。
如果在每个角色的首层都定义一个事务码，系统一样会重复显示。
当前用户权限检查可以使用SU53检查当前用户的权限。
程序中权限的检查通常使用任何T-code前一定会有权限检测的.AUTHORITY_CHECK:这个函数只是小检查一下你的user有没有,什么时候过期. 如果是代码只要使用此函数就够了.AUTHORITY_CHECK_TCODE:检查T-code下面的函数是真正检查autorization objects的.SUSR_USER_AUTH_FOR_OBJ_GET:AUTHORIZATION_DATA_READ_SELOBJ:End。