X-Recipient: archive-cygwin AT delorie DOT com DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:from:to:subject:date:message-id:references :in-reply-to:content-type:content-transfer-encoding :mime-version; q=dns; s=default; b=ktrfG+Ghm3FNPrLkB5/TDAvoPLn2/ NknmEktd86NmzyJehhaI0u9831xE8TmpomlO5DZfVViDwzqbyki9qaXEBZlxuMks ecx/RXudsrPZAw7w4TLOwNTGgQNaNXjUmT1DqJLxc/eP4z8Cx/8uC9fe6pxD5iPy slScsPpneJ0njk= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:from:to:subject:date:message-id:references :in-reply-to:content-type:content-transfer-encoding :mime-version; s=default; bh=l6cQRBE5HU+KjX5oT6VXmJiAhqs=; b=Jap Nu7BFxHI9PX2dIJ/6u/CzfVZ4yKJdASTG8BtWyvkHmYb9rAq7jl8ITYZvIhr0Zj1 3LgeVqvy4xiORoJizLrTsaaB630dOjPFdNyKq43I5p6ScIwImhk4Dpt9pizDo0XY 5JvREVzHK7uCSA+UPDwfgJt2j7cv2IUU3gByZwYk= Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.5 required=5.0 tests=AWL,BAYES_50,MIME_BASE64_BLANKS,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 X-HELO: nihxwayout.hub.nih.gov X-IronPortListener: Outbound_SMTP X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AicFAJxU9VKcKEfb/2dsb2JhbABZgwyBD4MBu3EYdhZ0giUBAQEDARIREUoLAgEIDQ0CBgsDEgICAh0TFQIBDQIEGxqHWwihR4ofoGoXgSmMaBQnOAoOglc1gRQEjmOQOIsxgW+BPoFoCRci From: "Lavrentiev, Anton (NIH/NLM/NCBI) [C]" To: "cygwin AT cygwin DOT com" Subject: RE: get rid of getpwent? (Was: cygwin-1.7.28 getpwent header declaration changes ?) Date: Fri, 7 Feb 2014 21:49:44 +0000 Message-ID: <5F8AAC04F9616747BC4CC0E803D5907D0C47C45C@MLBXv04.nih.gov> References: <52F339CA DOT 5070305 AT gmail DOT com> <20140206090117 DOT GD2821 AT calimero DOT vinschen DOT de> <52F361C5 DOT 3000807 AT gmail DOT com> <20140206141321 DOT GI2821 AT calimero DOT vinschen DOT de> <52F40208 DOT 5030901 AT etr-usa DOT com> <20140207094917 DOT GN2821 AT calimero DOT vinschen DOT de> <52F53D7C DOT 5050201 AT etr-usa DOT com> <20140207213013 DOT GT2821 AT calimero DOT vinschen DOT de> In-Reply-To: <20140207213013.GT2821@calimero.vinschen.de> Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 X-IsSubscribed: yes Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by delorie.com id s17Lo74v015340 > I think SAM/AD will be mostly quicker I do not want to be a party pooper here, but have you checked how the AD approach will work from the unmanaged Windows service accounts? We've been experiencing rather nasty effects of the M$ design that when a host changes its password (it is required to, every so many days), it is no longer considered an "authorized" agent (rather, anonymous). Accessing AD anonymously (esp. from system-managed service account) is limited; like when you request a list, you get only first 100 (who at M$ had invented this?!) entries. Which means that if your code is scanning, it won't find more than 100 users (and they are alphabetized, so the "excess" users will simply disappear from view). That creates false-positive nonexistent users / groups. The only remedy is to restart the host... P.S. I'm not an AD person, and some of the info from the above comes from our sysadmins (how they see things unfolding). Anton Lavrentiev Contractor NIH/NLM/NCBI