Single Sign On

Single Sign On (SSO) (tradução livre: login único) refere-se à técnica de criação de um servidor de logins, de maneira que todas as aplicações que precisem de autenticação por login e senha dentro de uma organização busquem sempre o login de um só lugar. Isso evita que existam diversos pares login/senha para cada usuário dentro da organização.

Existem alguns softwares que habilitam SSO em uma rede, como:

• OpenLDAP
• Active Directory

O padrão que funciona por trás desses softwares é o LDAP (Lightweight Directory Access Protocol) que oferece funcionalidade de serviços de diretório, que são bases de dados de sistema, (geralmente com conteúdo sobre serviços, máquinas, usuários e permissões na rede) e SSO é uma feature que se utiliza dos dados do diretório.

Os dois softwares podem ser usados para habilitar SSO em uma rede, porém algumas considerações podem ser tecidas, IMO:

• OpenLDAP é um pouco mais simples de configurar. Em ambientes linux ajuda a não heterogeneizar S.O., visto que nas distribuições atuais é possível sua instalação com alguns comandos simples do gerenciador de pacotes. Funciona na porta 389 (sem conexão criptografada) e na porta 636 (com criptografia SSL/TLS). Pode ser instalado tanto em servidores Windows e Linux.
• Active Directory é mais complexo de ser instalado, dado o mundo de características extras que a Microsoft recomenda a inclusão no mesmo servidor. Em geral, é recomendado colocar servidores DNS, DHCP, e NTP nesses servidores, e se isso não for respeitado, muitos detalhes surgirão para realizar a instalação de domínios filho, ou de florestas cópia, por conta de cláusulas específicas do AD que são postas nesses outros serviços. Por outro lado, quando se trata de um ambiente puro Windows, o deployment dos clientes é bastante simplificado, inclusive usando Windows AIK. Utiliza as seguintes portas LDAP 389, LDAP sobre SSL/TLS 636, Global Catalog 3268 Global Catalog over SSL/TSL 3269

Estou terminando aqui uma demo com OpenLDAP. Em breve posto os avanços!

Posted from GScribble.

Erro 4866 com Bulk Insert

Ao me deparar com a situação de realizar uma importação de dados para o SQL Server a partir de arquivos CSV, percebi q seria uma boa oportunidade de usar o BULK INSERT.

Meu CSV é separado por vírgulas e foi escrito em unix. Isso vai nos levar ao velho problema da representação de fim de linha que é diferente entre windows e *unix.

Quando um arquivo plain-text *unix for usado com o código abaixo, o SQL Server vai enviar sempre ao invés de \n, o conjunto \r\n.

BULK INSERT [Data2010-2] 
    FROM 'C:\dataWithoutHeads.csv' 
    WITH 
    ( 
        KEEPNULLS,
        FIELDTERMINATOR = ',', 
        ROWTERMINATOR = '\n' 
    )

Esta inconsistência, vai gerar 3 erros quando for executado:

Msg 4866, Level 16, State 1, Line 1

The bulk load failed. The column is too long in the data file for row 1, column 30. Verify that the field terminator and row terminator are specified correctly.

Msg 7399, Level 16, State 1, Line 1

The OLE DB provider "BULK" for linked server "(null)" reported an error. The provider did not give any information about the error.

Msg 7330, Level 16, State 2, Line 1

Cannot fetch a row from OLE DB provider "BULK" for linked server "(null)".

O grande erro a ser corrigido aqui é o 4866, que representa um erro no BULK INSERT. Os outros são consequência deste erro.

Para resolver isso de uma forma simples, no unix mesmo, antes de executar o bulk insert, use o aplicativo unix2dos. Ele existe em qualquer distribuição linux e irá “converter” as quebras de linha formato unix para o formato Windows (caso você precise fazer o caminho inverso, existe o aplicativo dos2unix) e sua sintaxe é bem simples. Em qualquer linux shell, digite:

$ unix2dos dataWithoutHeads.csv

A depender do tamanho do arquivo demorará bastante. Para se ter uma referência, na minha máquina (quad core 2.33GHz, 2gb de RAM) levou aproximadamente 10 min para converter 261MB de texto.

Agora, a execução do bulk insert será sem erros.

Extracting XML Schemas from XML

This is a simple post do announce a tool that I’ve made today for creating XML Shemas from XML documents from the command line.

Well for my simplicity, the tool is not fully command line-like, but later I’ll fix that. The good use I’ve found was to pipe the schema produced to a file on the cmd.

This sounded me as a good tool to be avaliable on PowerShell. A future enhancement to be done.

Download Here!

References:

[1] http://msdn.microsoft.com/en-us/library/xz2797k1.aspx

[2] http://technet.microsoft.com/en-us/scriptcenter/dd742419.aspx

Introdução ao P/Invoke

Segue abaixo um vídeo q fiz (nos moldes da série How do I que a Microsoft anda promovendo nos seus sites de aprendizado) para falar um pouco sobre interoperabilidade entre .NET Framework (C#) e DLL’s nativas escritas em C/C++.

Este será o primeiro vídeo de uma série sobre o tema. Opinem!

First (?) Announcement of Windows 7 Failure

Today on twitter, @lauromoura has tweet a report about a Windows 7 failure. See the link:

http://seclists.org/fulldisclosure/2009/Sep/0039.html

Worth to see, what Steve Ballmer said on Vista’s release and the press opinions: here.

Fact: no Windows (and no Operating System) will be totally secure. It’s all just a matter of time.

Searching columns by type

Today I went to review the SQL Server 2008 enhancements on XML support. To test the queries on AdventureWorks, the first thing I needed to know was: “Where are the XML data columns?”

I don’t actually have the graphic on the database model to search for and wasn’t on the mood to create the database diagram to search visually for the XML columns.

Then, I’ve got the idea of searching on the catalog for that. It should be simple to do (and it was!) but worth the post, as many people may have the need to use the same thing, not only on AdventureWorks, but on large (I mean many tables) databases:

Here is the script:

SELECT t.name, c.name, ty.name
  FROM sys.tables t INNER JOIN sys.columns c  ON
          (t.object_id = c.object_id)
      INNER JOIN sys.systypes ty ON
          (c.system_type_id = ty.xtype)
WHERE ty.name = ‘xml’

With this script, you can create a procedure that returns the table name and the column name that uses a type that’s passed by a parameter. Or even create a PowerShell function to achieve this. Let’s see the latter:

param([string] $typeName, [string] $server, [string] $database)
$sqlConnection = New-Object System.Data.SqlClient.SqlConnection "server=$server;database=$database;Integrated Security=sspi"
$sqlConnection.Open()
$sqlCommand = $sqlConnection.CreateCommand()
$sqlCommand.CommandText = "SELECT t.name [Table], c.name [Column]
                                                  FROM sys.tables t INNER JOIN sys.columns c
                                                          ON (t.object_id = c.object_id) 
                                                                           INNER JOIN sys.systypes ty 
                                                          ON (c.system_type_id = ty.xtype)
                                               WHERE ty.name = ‘$typename ‘"
$sqlReader = $sqlCommand.ExecuteReader()
$dataTable = New-Object System.Data.DataTable
$dataTable.Load($sqlReader);
$sqlConnection.Close()
Write-Output $dataTable

Interesting, huh?

MCTS: SQL Server 2005

Bem, um pouquinho tarde, mas enfim, passei nesse sábado na prova 70-431: Microsoft SQL Server 2005 – Implementation and Maintenance, inaugurando a minha intenção de me especializar em banco de dados.

A prova é composta de duas partes, uma com 35 questões objetivas, e outra com 12 questões de simulação. A parte objetiva é bem tradicional, e pelo menos as questões que foram selecionadas na minha prova foram bem distribuídas nos assuntos. Houveram questões de XML, de desenvolvimento com CLR, backup/restore, … acho que só não caiu de Service Broker. Na parte prática, tive sorte e das 12 questões, 4 foram sobre backup/restore (para configurar um backup de acordo com algumas características pedidas).

Agora é estudar pra atualizar pra MCTS: SQL Server 2008!

Backup no SQL Server 2008

Este vai ser um post sobre um tema introdutório para administradores de banco de dados. Uma tarefa comum que deve ser realizada de tempos em tempos e pela sua importância, é importante que ocorra com frequência, para que se tenha segurança com relação a algum desastre que possa acontecer… ninguém sabe quando um erro pode ocorrer, ou quando os dados podem ficar corrompidos, por esse ou aquele motivo.

Dentro do SQL Server 2008, os backups podem ser feitos de algumas formas:

• Full
  • Faz o backup de todo o banco de dados. Isso inclui não somente o arquivo de dados mas também o log de transações, e com isso representam todo o banco de dados num determinado momento do tempo.
  • Sintaxe: BACKUP DATABASE <NOME_DO_DATABASE> TO DISK =<CAMINHO_PRO_ARQUIVO_DE_BACKUP>;
  • Ex.: BACKUP DATABASE teste TO DISK = N’C:\Backups\teste.bak’;
• Differential
  • Não confundir com backup incremental. Este backup diz respeito as diferenças ocorridas no banco de dados após o último full backup. Um backup incremental armazenaria as diferenças entre o momento atual e o último backup (que não necessariamente seria full);
  • De acordo com o que foi exposto acima, não é possível então, fazer um backup diferencial sem antes ter feito um backup full;
  • Por manipularem somente as diferenças entre um backup full e o estado atual, tendem a ser sempre backups mais rápidos de serem executados, e menores no espaço em disco ocupado;
  • Sintaxe: BACKUP DATABASE <NOME_DO_DATABASE> TO DISK <CAMINHO_PRO_ARQUIVO_DE_BACKUP> WITH DIFFERENTIAL;
  • Ex.: BACKUP DATABASE teste TO DISK = N’C:\Backups\teste.bak’ WITH DIFFERENTIAL;
• Log Full
  • Realiza o backup total do log de transações;
  • Sintaxe: BACKUP LOG <NOME_DO_DATABASE> TO DISK <CAMINHO_PRO_ARQUIVO_DE_BACKUP>;
  • Ex.: BACKUP LOG teste TO DISK = N’C:\Backups\teste.trn’ WITH DIFFERENTIAL;
• Log Differential
  • Realiza o backup diferencial do log de transações;
  • Sintaxe: BACKUP LOG <NOME_DO_DATABASE> TO DISK <CAMINHO_PRO_ARQUIVO_DE_BACKUP> WITH DIFFERENTIAL;
  • Ex.: BACKUP LOG teste TO DISK = N’C:\Backups\teste.trn’ WITH DIFFERENTIAL;

Apesar de usarmos as extensões bak e trn, não há obrigatoriedade dessas extensões, sendo somente uma boa prática as que foram usadas nos exemplos.

No SQL Server 2008 foi introduzida uma novidade que é a compressão de backup. Por default este é um recurso que está desativado. Para poder usar como um recurso padrão para todos os backups, primeiro é preciso reconfigurar a base de dados, com:

sp_configure ‘backup compression default’, 1;
go

reconfigure;

Com isso, habilitamos no servidor a compressão de backup por default, o que significa que todo banco de dados terá backups comprimidos. Foi então adicionada a query de backup a opção do with COMPRESSION ou NO_COMPRESSION, para que se possa escolher na query se se deseja um backup comprimido ou não.

Além destas formas, também é possível usar a simples estratégia de Attach/Detach que é extremamente conveniente, quando se pode deixar o banco off-line por algum tempo.

[1] White Paper sobre compressão de backup no SQL Server 2008
[2] Backing Up and Restoring How-to Topics
[3] Copy-Only Backups
[4] Full Database Backups
[5] Differential Database Backups

Who’s connected to my SQL Server?

There are two easy ways to do this. The SQL Server, have two procedures, sp_who and sp_who2 that solves this problem. Syntax:

sp_who 'loginname'

The sp_who procedure shows information about the actual users, sessions and process in a instance of SQL Server. Can be executed without parameters, and returns info about all users and sessions and processes.

The sp_who2 procedure show the same information that sp_who shows (and works the same way too), but adds the cpu time and disk io consumption on the result.

Another way is use the query below, you can retrieve the same information (in less detail) from the sysprocesses system view.

SELECT DB_NAME(dbid) as [database]
                        [login_time], 
                        [open_tran], 
                        [nt_username]
                        [hostname], 
                        [program_name] 
  FROM master..sysProcesses

[1] sp_who documentation

[2] Forum Messages about sp_who and sp_who2 (Portuguese)

Windows Vista Performance Roundtable

With the launch of Windows Vista SP1 giving some significant fixes on performance issues on the operating system, Microsoft tries to take off the slow adjective from the mouth of users who tried Windows Vista.

Personally, SP1 really had improved performance, but much more can be done to take it better.

Below is a round table with Microsoft specialists, that’s very interesting to understand what can be done to take the performance of day-to-day operations better.

Springboard Series Virtual Roundtable: Windows Vista Performance