No final do ano, todo mundo está avaliando lentamente.

Para mim, este ano foi lembrado pelo projeto de implementação do Single Sign On (SSO) entre SAP e Windows. Neste artigo, falarei sobre a experiência de implementação e gerenciamento de projetos, armadilhas, descobertas e conclusões.

A empresa é uma grande empresa de transporte na Bélgica, combinando metrô, bonde e ônibus. São mais de 10 mil funcionários, dos quais quase dois mil são backoffice, usando muitas ferramentas: site corporativo, correio, serviço de aplicativo, sharepoint, arquivista e, é claro, SAP.

A SAP está em todo lugar: da contabilidade e RH ao registro de movimentação de unidades de transporte, documentação de acidentes, análises, compras, armazenagem, etc.

Problema:

• O usuário do SAP for PC é um aplicativo separado para o qual você precisa da sua senha
• Primeiro você precisa solicitar uma senha e depois lembrar. O suporte técnico é forçado a receber chamadas para criar e alterar senhas.
• Do ponto de vista do usuário, uma senha extra é um aborrecimento extra. As pessoas armazenam senhas em papel ou as tornam muito simples. A segurança grita sobre violações graves.
• Os requisitos mínimos para uma senha para um PC não correspondem às configurações de senha no SAP. Se você os levar a um denominador comum, é melhor implementar imediatamente o SSO.

Objetivo: implementar um SSO entre o Windows e o SAP, para que, ao fazer login na sua conta de PC, o usuário possa efetuar login no SAP sem inserir uma senha.

Se você não lida com a SAP, estará interessado neste artigo do ponto de vista do gerenciamento de projetos, pois os detalhes desses detalhes serão fornecidos (entre colchetes).

Sob o corte:

1. Âmbito de aplicação
   1.1 Pessoas do escopo
   1.2 Sistemas de escopo
2. Componentes
   2.1 Alterando parâmetros do sistema
   2.2 Diretório Ativo do Windows (AD)
   2.3 SAP Secure Login Client (SLC)
   2.4 Vinculando um usuário SAP ao seu AD
   2.5 Modificando o arquivo logon.ini do SAP
3. Teste
4. SNC é uma brecha na segurança
5. Trabalho em equipe
6. Informações comerciais
7. Dificuldades de tradução
8. Resumo e Conclusões

1. Introdução

Olhando para o futuro, se você não estiver disposto a preencher cones padrão, aqui está uma lista de perguntas que você deve esclarecer no início do projeto:

• Escopo do projeto (sistemas, usuários - em que ordem estamos implementando, qual é a prioridade e o que pode ser descartado se algo der errado, quais usuários devem ter acesso etc.)
• Os principais departamentos afetados pelo projeto (mesmo que o projeto seja tangencial, ainda é importante que todos sejam informados com antecedência)
• Seus poderes (não é muito fácil fugir daqui - em uma empresa européia tudo se baseia no consentimento e no desejo voluntário de ajudar. Se o departamento disser que eles não têm recursos, é quase impossível pressionar e "forçar". Mas você pode chamar um consultor externo para obter ajuda, por exemplo)
• Tempo (para todo o projeto como um todo e para partes específicas)
• Procedimentos de aprovação (Regulamentos burocráticos - em uma grande empresa, essa não é a última pergunta)
• Possíveis dificuldades (Tudo. Possíveis. Dificuldades.)

Alteramos a associação do projeto várias vezes: no início, era apenas o departamento de autorização no SAP e o departamento de administradores (Componentes Básicos). Em seguida, eles se juntaram ao departamento de autorização no Windows (Active Directory, AD) e ao departamento de implementação de atualizações (Empacotamento), depois ao departamento de bancos de dados e ao departamento de aplicativos móveis, etc.

Um consultor externo foi convidado para o lado técnico do assunto, e o gerente de projeto (PM) se tornou eu, como pessoa envolvida na autorização no SAP (portanto, haverá mais detalhes sobre a autorização no SAP neste artigo do que outros).

Um esclarecimento importante: todo o acesso que oferecemos no SAP é personalizado. Não usamos as funções padrão que o sistema oferece, mas criamos novas, por departamento, por posição, por função. Até o momento, não temos sincronização entre usuários do SAP e do Windows AD. Por exemplo, se seu usuário tiver direitos de administrador na rede local, isso não significa que ele também seja um administrador no SAP.

1. Âmbito

1.1 Pessoas do escopo

As pessoas de nossa empresa usam o SAP através de um aplicativo em um computador pessoal (thin client - SAP Logon GUI), mas não apenas. Como contar os usuários classificados em distribuição?

Tomamos como base todos os que se conectam diariamente via SAP Logon (tipo de usuário SAP Dialogue) a partir de laptops. Nesta categoria, todo o backoffice - equipe de administração, bukhs, Ichars, desenvolvedores, testadores, logística, etc.

Excluídos:

• aqueles que têm um computador de mesa, não um laptop
• 8 mil usuários que nunca abrem o logon do SAP, mas usam o SAP no site e nos aplicativos (Comunicação do tipo de usuário do SAP)
• todos os usuários externos (não funcionários, mas devem fazer login no sistema via VPN)

1.2 Sistemas de escopo

Em nossa empresa, a SAP usa seis cenários ativos ( ECC, BI, SRM, Netweaver, PI, gerente de soluções ), sem contar as caixas de proteção. Cada um deles tem seu próprio DEV , ACC , PRD - ou seja, de fato, são 6 * 3 = 18 sistemas.

Pela votação das vogais, foi decidido tirar apenas as quatro primeiras paisagens. O PI e o SM são usados ​​por um círculo restrito de administradores e exigem a atualização do próprio sistema (pelo menos, a atualização do componente SAP_BASIS para a versão 740). Caso contrário, a transação sncwizard não é suportada e fazer isso manualmente é muito problemático para 10 a 20 pessoas.

2. Componentes

As pessoas interessadas nesses detalhes encontrarão instruções passo a passo no site da SAP , bem como os vários métodos disponíveis (escolhemos o SSO baseado no Kerberos , mas essa nem sempre é uma opção óbvia).

De um ponto de vista muito simplificado (o meu), o SSO é um complemento no SAP que permite fazer login usando sua conta do Windows. Você liga o computador, insira a senha e, para fazer login no SAP, basta clicar duas vezes.

Para que a mágica funcione, você precisa de 5 componentes:

2.1 Alterando parâmetros do sistema (instâncias SAP)

No sistema SAP ( ECC , BI , SRM , Netweaver ), é necessário ativar o parâmetro snc / enable = 1. Isso é feito através do sncwizard e inclui etapas de preparação, reinicialização do sistema e ativação final.

Descobrimos os parâmetros antes e depois com a ajuda desses consultores, assistência de outros departamentos e tentativa e erro. A coisa mais difícil aqui foi reiniciar o sistema.

Sempre é difícil reiniciar o PRD na produção; o trabalho está acontecendo o tempo todo. E em uma empresa de transporte isso é duplamente mais complicado: o transporte muda das cinco da manhã até a uma da manhã, mesmo nos finais de semana. Quaisquer dificuldades com o PRD afetam não apenas os funcionários da empresa, mas toda a cidade e dezenas de milhares de pessoas. Em outras palavras - você precisa minimizar o tempo em que o sistema não está disponível e, se possível, combinar com outras atualizações. Ao mesmo tempo, a burocracia não deve ser subestimada: reiniciar é uma data, hora, duração (se os parâmetros não forem salvos na primeira vez) e uma notificação comercial.

Tínhamos quatro sistemas SAP PRD: ECC, Netweaver, SRM, BI - para reinicialização

O ECC é o mais importante, todos os dados em tempo real e o transporte principal estão ligados a ele: ônibus, bondes.

Os dados do sistema Netweaver (acidentes, aplicativos móveis), bem como dos sistemas ECC, são usados ​​até às 3 da manhã - se os bondes não saem, as equipes de reparo vão embora.

Sistema SRM - usado principalmente para compras e estava disponível qualquer dia após as 18:00.

Com o BI, a dificuldade é que, nos fins de semana, os fluxos de dados do ECC vão para o sistema; além disso, às vezes os relatórios do BI são usados ​​pela alta gerência fora do horário comercial.

No total, foram necessárias duas semanas para reiniciar todos os PRDs.
PS A reinicialização de cada um dos sistemas PRD foi precedida pela reinicialização de todos os DEV e ACC, que são mais fáceis de coordenar, mas também exigem planejamento.

2.2 Diretório Ativo do Windows (AD)

O Active Directory requer a criação de um usuário técnico especial (SAP Kerberos). Este usuário entrará em contato com o Windows para obter uma cópia do ticket de entrada para SAP. Um desses usuários do serviço AD é suficiente para todos os sistemas SAP.

Essa parte foi inteiramente feita por nosso consultor externo e pela equipe do Active Directory, incluindo várias iterações para refinar os parâmetros e configurar a biblioteca especial, mas para mim permaneceu mais uma "caixa preta".

2.3 Instalando o SAP Secure Login Client (SLC) no computador de um usuário

Este programa por si só não faz nada. Você precisa armazenar um ticket do AD que confirme seu usuário ao fazer login em uma sessão do Windows e, se necessário, envie esse ticket ao SAP para autorização. O SLC pode ser instalado para todos os usuários imediatamente no início do projeto - sem os outros componentes SSO, ele não funcionará de qualquer maneira.

2.4 Vinculando um usuário do SAP ao seu usuário do AD

Como já mencionado, em nossa empresa não existe um gerenciamento único de usuários, o acesso a diferentes sistemas é obtido de diferentes equipes. Nesse caso, o login do usuário no SAP é diferente do nome do usuário no Windows; por exemplo, o usuário # 45011 no AD é Ivan Ivanov ou IVANOVI . É esse grupo que precisa ser preenchido no SNC (por meio da transação SU01, campo SNC, p: CN = ADname @ domain).

Nossa empresa não possui o SAP Identity Management. Portanto, foi necessário resolver dois problemas: criar novos usuários e atualizar os parâmetros dos já existentes.

Crie novos usuários
No sistema principal (ECC), todos os dias úteis, são criados de 4 a 6 novos logins, são quase 1000 novos usuários por ano. O processo é automatizado: ao criar um usuário, o programa preenche seu endereço, nome, configurações básicas. Decidimos que o programa também deve preencher o campo SNC no estágio de criação do usuário, independentemente de a pessoa precisar do SSO no SAP posteriormente ou não.

O problema foi que, para cada usuário, você precisa preencher um nome exclusivo no AD, ou seja, não é o mesmo parâmetro para todos - ou seja, é necessário que o próprio programa procure o nome de usuário no AD e o preencha no SAP.

O desenvolvedor atualizou rapidamente o programa. O código e os testes básicos levaram 2 dias, mas os dados para verificação no ACC não eram adequados para nós (o AD não foi atualizado), por isso enviamos imediatamente as alterações ao PRD. Acabou que tudo é mais complicado do que pensávamos. No decorrer da investigação, chegamos ao seguinte esquema:

1. Primeiro, os usuários são criados no sistema de RH (no SAP, eles podem ser vistos no PA20 )
2. Em seguida, eles são copiados para a tabela Z, juntamente com os dados sobre o departamento, posição, posição, se é o link principal etc.
3. Em seguida, os dados do usuário são enviados para o AD e aqui o sistema cria um usuário no Windows e fornece um nome no AD e no correio
4. O fluxo do PI neste diagrama é simplesmente para entender que é um processo de terceiros do terceiro sistema
5. Os dados são copiados de volta para o SAP (na nova tabela Z), desta vez apenas os nomes e endereços de email do AD
6. No último estágio, o programa Z é iniciado, o que cria usuários no SAP ( SU01 ). Nem todos os usuários criados no sistema de RH serão criados posteriormente no SAP; muitos são os que, em última análise, não usam o SAP

Demorou quase duas semanas para pesquisar, coordenar alterações, concordar com um cronograma para atualizar e carregar / descarregar tabelas. Era uma questão de sincronização - o programa de criação do usuário (ponto 6) deve ser estritamente iniciado depois que todos os outros programas já tiverem funcionado e os dados forem copiados para as tabelas. Como resultado, rastreamos por duas semanas quando o programa terminou e a que horas e depuramos o esquema.

Quando os usuários são criados com um campo SNC preenchido, mas sem os nomes necessários do AD, em SU01, é possível ver todos os infelizes usuários associados a um usuário inexistente do AD.

Atualizando configurações de usuário existentes
Precisamente porque nosso SAP e Windows de login não coincidem, não conseguimos usar a solução SAP padrão para preenchimento em massa no campo SNC ( RSUSR300 via programa SNC1 ).

Como resultado, atualizei os dados de 10 mil usuários existentes usando um script improvisado ( SAP eCATT ), carregando manualmente os dados do usuário e criando uma variante. Para ter sucesso, tive que abrir para alterar os sistemas eCATT no PRD e no ACC e prometer aos desenvolvedores milhões de cookies.

2.5 Modificando o arquivo logon.ini do SAP

Tecnicamente, isso é 1 minuto. É necessário apenas observar nas propriedades do arquivo que a conexão via SNC está disponível .

A dificuldade é que esse arquivo está localizado localmente no PC do usuário e dois mil usuários precisam alterá-lo.

De fato, para nós, a implementação final foi o momento de distribuir o novo arquivo sap.logon.ini entre os usuários, em vez de alterar os parâmetros do PRD. Porque mesmo que os quatro primeiros componentes já estejam prontos e o último quinto não esteja, a mágica não acontecerá.

Com o último parágrafo, veio um pequeno incidente. Eu relatei ao gerenciamento que possuímos 2.000 usuários que terão a atualização instalada e, quando chegou a hora de implementá-la, eles me enviaram um status em que havia 3.500 deles. Isso porque, da minha parte, vi apenas usuários ativos da SAP, mas, na realidade, a atualização foi enviada a todos os laptops pessoais, que são muito mais na empresa. Graças a Deus não surgiram erros técnicos.

3. Teste

Como testar o SSO? Ou funciona ou não. Nosso desenvolvedor bufou e disse que não é necessário testar nada e, assim que tudo funcionar na sandbox, você precisará enviá-lo para produção. Claro. Ninguém dirá que ele escreve código com bugs.

Você precisa verificar:

• O login do SAP funciona com o SSO logo após a reinicialização
• os usuários podem usar o SSO quando conectados à VPN
• dificuldades para desenvolvedores de outros sistemas para modificar o logon do SAP

O SSO não é um programa, é difícil implementá-lo consistentemente DEV - ACC - PRD. No entanto, o teste inicial é necessário para capturar tudo o que poderia dar errado. O teste neste caso é a distribuição do novo SAP logon.ini quando todos os componentes já estiverem em execução. Testamos o DEV e o ACC com os desenvolvedores e o novo SAP logon.ini com o PRD com uma seleção de usuários corporativos.

O que eles encontraram:

• às vezes (1 caso por 500), é necessário reinstalar completamente o logon do SAP ou o SLC
• principais usuários que têm direitos para alterar outros usuários (mais sobre isso no próximo parágrafo)

4. SNC é uma falha de segurança

Que tal modificar o campo SNC?
O fato é que, alterando o campo SNC de outro usuário (em SU01) para o seu, você pode conectar-se à conta de outra pessoa sem alterar a senha. O sistema simplesmente perguntará a você qual usuário escolher, seu ou de outra pessoa. No entanto, se você fizer isso, amanhã ninguém notará nada, porque a senha permaneceu inalterada.

Em qualquer empresa, há pessoas envolvidas no gerenciamento de usuários . Normalmente, essas pessoas monitoram a criação de usuários ( SU01 ) e acessam por eles ( PFCG ), além de atualizações de senha. É lógico que eles também possam preencher o campo SNC .

O problema surge quando a empresa precisa separar o gerenciamento de usuários e apenas os principais usuários. Os administradores criam usuários e os principais usuários, se necessário, alteram seus dados: parâmetros do usuário, idioma, localização, etc.

No SAP, não há etapa de controle separada para alterar o campo SNC. Todos os que têm direitos para alterar o usuário (objeto S_USER_GRP, ACTVT 02 ) também podem alterar o campo SNC (enquanto a alteração da senha requer o mesmo objeto, mas com o ACTVT 05 ).

Pode haver várias soluções:

• tirar direitos de acesso ao SU01 dos principais usuários e, em resposta, fornecer a todos SU2 e SU3, onde o usuário pode alterar seus próprios parâmetros
• retire os direitos de acesso ao SU01 e, em troca, forneça uma transação z onde a guia SNC não será mostrada
• deixe SU01, mas proteja o campo SNC com controle especial

Como resultado, escolhemos a última opção criando um objeto de autorização personalizado e vinculando o programa SU01. No entanto, como se descobriu mais tarde, a SAP tem uma solução semelhante - você pode ativar a manutenção estendida ( nota 1882254 ) para campos individuais SU01.

5. Trabalho em equipe

Durante o projeto, encontrei todas as dificuldades do trabalho em equipe e descobri muitas verdades básicas:

• Nunca há muito tempo . A margem de tempo é a melhor que o PM pode oferecer.
• Deve haver um plano básico do projeto , mas ele precisa ser revisado toda semana, deixando uma grande margem de flexibilidade. Em algum lugar nos movemos mais rápido, em algum lugar pisoteado no local.
• Às vezes, os tios adultos no departamento de TI não diferem no comportamento das meninas na contabilidade : eles se recusam a trabalhar um com o outro, simplesmente porque não gostam da pessoa. E mais uma vez é necessário resolver questões de subordinação.
• Muitas vezes, os departamentos dificultam a aprovação do projeto , porque não está claro quem é responsável pela implementação e cujo orçamento horas adicionais caem. É importante deixar os gerentes discutirem tudo diretamente.
• Situações imprevistas surgem de vez em quando . O melhor que pode ser é a comunicação oportuna, uma carta, uma chamada, SMS para todas as pessoas envolvidas.
• Não há nada melhor do que uma reunião pessoal . As perguntas são resolvidas muitas vezes mais rapidamente do que quando discutidas pelo correio. Por outro lado, todos os arranjos pessoais devem ser seguidos imediatamente por uma carta subsequente (para corrigir e não esquecer)
• O gerente de projetos em um projeto de TI pode confiar apenas nas pessoas . Na verdade, você não tem idéia de quanto tempo levará essa ou aquela ação: por exemplo, criando um usuário no AD para Kerberos, 10 minutos ou três dias? E não há como verificar se o teste realmente parou ou se alguém estava brincando. Resta apenas confiar.

Além disso, depende muito da perseverança do consultor. Alguém sozinho, ou um consultor de desenvolvimento ou PM, deve ser tão insolente quanto uma bala e socar as paredes de uma burocracia. Nesse caso, tive uma sorte parcial, nosso consultor convidado era irritante e às vezes insuportável (era difícil fazê-lo ouvir alguma coisa), mas ele conhecia a empresa: relatava problemas e parava imediatamente e não se acalmava até que o problema fosse resolvido.

6. Informações para negócios

Em uma grande empresa, as mudanças que afetam os usuários finais devem ser oportunas e melhor anunciadas com antecedência.

No nosso caso, era necessário informar a todos os usuários que agora eles não precisam de uma senha para entrar no SAP. Além disso, era necessário fornecer documentação técnica para a 1ª linha de suporte com todos os erros possíveis que possam surgir após a implementação.

Devo admitir que com a comunicação tudo o que poderia ter dado errado.

Em primeiro lugar , anunciamos aos usuários sobre o SSO no site corporativo, e não por carta. Com que frequência você lê um site corporativo? SAP .

- , , , , , , , ( - ?) , .

- , Go Live, , ( 2 ), . .

7. fuck-up

5- SSO SAP, , .

: . , — . . 2- , 500 -. .

. “use a default language SAP logon” — , , ( SU01 , Defaults ). « SAP» .

, -, .

- .

8.

SSO — , . , 1-2 , 3- .

. . , , , .

SSO , , , , . AD, SNC. , . , ( , ) — .

 ,     ,   . 

Sólidos:

• O tempo principal em três meses foi gasto na coordenação e coordenação de ações
• Os departamentos envolvidos neste projeto começaram a entender melhor o trabalho um do outro.
• Durante o teste, você precisa se apresentar no lugar do usuário final - o que você gostaria de ver na mensagem informativa e nas configurações básicas.
• SSO para SAP é implementado. Os usuários estão felizes e já se esqueceram dos momentos em que era necessário lembrar a senha da SAP. Ligue para o suporte técnico com menos frequência, felicidades.