Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1s66sd-00A95p-EK for pgsql-admin@arkaria.postgresql.org; Sun, 12 May 2024 10:56:36 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1s66sb-00APYp-Hu for pgsql-admin@arkaria.postgresql.org; Sun, 12 May 2024 10:56:33 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1s66sb-00APYg-50 for pgsql-admin@lists.postgresql.org; Sun, 12 May 2024 10:56:33 +0000 Received: from cc-smtpout3.netcologne.de ([89.1.8.213]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1s66sU-000eGx-Ia for pgsql-admin@lists.postgresql.org; Sun, 12 May 2024 10:56:32 +0000 Received: from cc-smtpin2.netcologne.de (cc-smtpin2.netcologne.de [89.1.8.202]) by cc-smtpout3.netcologne.de (Postfix) with ESMTP id 17A3712209 for ; Sun, 12 May 2024 12:56:26 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=netcologne.de; s=nc1116a; t=1715511386; bh=Imt8vkTE2Ue7oZMvatepCt+6jAPS72xTtekYIkIxGT0=; h=Message-ID:Date:Subject:To:References:From:In-Reply-To:From; b=fF0ZmhUGjdpW9b+ODIbVY5vaecJeEsxvPcXOBpPHEhfWB5KR2Sthvp6K+CjUR4bpU 3Mu7uPxwkpN/Z6ajWL879JTpj9xeOBMr6GXAfquB+ggry5t0IYkpBCYoKDi2+xXUQZ 14RfxcgB037Xqde7iMr3HMyWVUMRk4ohw9KHcrf/N1BDGS920Rs+8mL4yUfoLkbiwl VqAvX0QPHgMeK7Dy+dCAmLB2epS3xIQLnetgZj2GXrNirFOu42j9RtaEMiFREmLdDg dnk+PBqahuIU3ExXeRQhKpcD7ActA1m54VDYzlS723mY0xzNr6R6pI3+hWX3znNKqm YFvgGEBzJGnxQ== Received: from [IPV6:2a03:b580:aa39:a502:fb12:e328:e5f:22cc] (unknown [IPv6:2a03:b580:aa39:a502:fb12:e328:e5f:22cc]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by cc-smtpin2.netcologne.de (Postfix) with ESMTPSA id 9BFD411DB5 for ; Sun, 12 May 2024 12:56:25 +0200 (CEST) Content-Type: multipart/alternative; boundary="------------l0xtFyH1ONj90shzmUGDl2Yb" Message-ID: <7491004d-73f1-4c5f-aaaa-e397c0ba5c1b@netcologne.de> Date: Sun, 12 May 2024 12:56:33 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Guidance on user deletion To: pgsql-admin@lists.postgresql.org References: Content-Language: en-US From: vrms In-Reply-To: X-NetCologne-Spam: L X-Rspamd-Queue-Id: 9BFD411DB5 X-Spamd-Bar: - X-Rspamd-Action: no action List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk This is a multi-part message in MIME format. --------------l0xtFyH1ONj90shzmUGDl2Yb Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit > The five account systems I've had experience with (OpenVMS, Linux, > Active Directory, SQL Server, Postgresql) all have the ability to > expire users, and to unexpire them if the person ever returns. how do you practically expire an account in postgres? On 5/11/24 5:55 AM, Ron Johnson wrote: > On Fri, May 10, 2024 at 2:37 PM Wetmore, Matthew (CTR) > wrote: > > Corporate env. > > I’ve searched for an official BestPractice on user  deletion > (leave company), but can’t find anything that is official-ish. > > Two options: > > 1. Change user psswd to nonsense, then expire account. > 2. DROP user. > > There are +/- to both. > > I prefer #1, as it gives the exact timestamp of expire (protects > company and ex-employee), but corporate auditors disagree. > > What do you do?  Any official guidance on this? > > > The five account systems I've had experience with (OpenVMS, Linux, > Active Directory, SQL Server, Postgresql) all have the ability to > expire users, and to unexpire them if the person ever returns.  (That > happened to me; my AD account was still there; they just reactivated > it...) > In *every* audit that I've gone through (and I go through them *every > year* because of PCI) the auditors are perfectly happy to see that > accounts are disabled. Occasionally they ask to see the log entry > generated when one tries to log into Postgresql with an expired account. > --------------l0xtFyH1ONj90shzmUGDl2Yb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

The five account systems I've had experience with (OpenVMS, Linux, Active Directory, SQL Server, Postgresql) all have the ability to expire users, and to unexpire them if the person ever returns.
how do you practically expire an account in postgres?



On 5/11/24 5:55 AM, Ron Johnson wrote:
On Fri, May 10, 2024 at 2:37 PM Wetmore, Matthew (CTR) <Matthew.Wetmore@evernorth.com> wrote:

Corporate env.

 

I’ve searched for an official BestPractice on user  deletion (leave company), but can’t find anything that is official-ish.

 

Two options:

 

  1. Change user psswd to nonsense, then expire account.
  2. DROP user.

 

There are +/- to both.

 

I prefer #1, as it gives the exact timestamp of expire (protects company and ex-employee), but corporate auditors disagree.

 

What do you do?  Any official guidance on this?


The five account systems I've had experience with (OpenVMS, Linux, Active Directory, SQL Server, Postgresql) all have the ability to expire users, and to unexpire them if the person ever returns.  (That happened to me; my AD account was still there; they just reactivated it...)
 
In every audit that I've gone through (and I go through them every year because of PCI) the auditors are perfectly happy to see that accounts are disabled.  Occasionally they ask to see the log entry generated when one tries to log into Postgresql with an expired account.

--------------l0xtFyH1ONj90shzmUGDl2Yb--