From jb25718@sac.sfbay.sun.com Fri Apr 9 14:46:22 2010 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o39LkMp3015419 for ; Fri, 9 Apr 2010 14:46:22 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o39LkL2R023549; Fri, 9 Apr 2010 14:46:22 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L0M0090BPT9MO00@brm-avmta-1.central.sun.com>; Fri, 09 Apr 2010 15:46:21 -0600 (MDT) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L0M0012PPT9J470@brm-avmta-1.central.sun.com>; Fri, 09 Apr 2010 15:46:21 -0600 (MDT) Received: from sac.sfbay.sun.com (sac.SFBay.Sun.COM [129.146.226.132]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o39LkLNc004234; Fri, 09 Apr 2010 14:46:21 -0700 (PDT) Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o39LkJp1015414; Fri, 09 Apr 2010 14:46:19 -0700 (PDT) Received: (from jb25718@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id o39LkJ50015410; Fri, 09 Apr 2010 14:46:19 -0700 (PDT) Date: Fri, 09 Apr 2010 14:46:19 -0700 (PDT) From: Jordan Brown Subject: idmap show -V mapping trace mechanism [PSARC/2010/125 FastTrack timeout 04/16/2010] To: PSARC-ext@sun.com Cc: smb-eng_ww@oracle.com, winchester@sun.com Message-id: <201004092146.o39LkJ50015410@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 3490 Template Version: @(#)sac_nextcase 1.70 03/30/10 SMI This information is Copyright (c) 2010, Oracle and/or its affiliates. All rights reserved. 1. Introduction 1.1. Project/Component Working Name: idmap show -V mapping trace mechanism 1.2. Name of Document Author/Supplier: Author: Jordan Brown 1.3 Date of This Document: 09 April, 2010 4. Technical Description SUMMARY Provide a mechanism whereby an administrator can examine in detail the steps used to map a Windows identity to a UNIX identity, or vice versa. BACKGROUND The idmap subsystem provides a mechanism to map Windows identities to UNIX identities, and vice versa, using a mixture of hardcoded data, rules, directory-based information, and algorithms. The "idmap show" command allows the administrator to determine the mapping resulting for any given input identity and to determine the mapping mechanism finally used, but does not reveal, for instance, why other mapping mechanisms were not chosen. PROBLEM Existing tools do not provide enough information to enable easily diagnosing why a particular mapping does not yield the expected result. PROPOSAL When requested using "idmap show -V", during each step of the processing of a mapping, record the state of the mapping process and a message describing the results of the particular step. Provide this recorded data as part of the output from the command. DETAILS Add a new "-V" option to idmap show. When specified, this option causes all significant decision points in the processing to be recorded and, on completion of the request, reported to the user. Sample output: $ idmap show -cV administrator@example.com winuser:administrator@example.com -> uid:2147491841 Trace: winname administrator@example.com -> unknown - Start mapping winname administrator@example.com -> unixname - Not a well-known account winname administrator@example.com -> unixname - Not a local SID winname administrator@example.com -> unixname - Not found in mapping cache winname administrator@example.com -> unixname - Not found in name cache winuser Administrator@example.com S-1-5-21-3591674789-480817656-4239000414-500 -> unixuser - AD lookup winuser Administrator@example.com S-1-5-21-3591674789-480817656-4239000414-500 -> unixuser - No matching rule winuser Administrator@example.com S-1-5-21-3591674789-480817656-4239000414-500 -> unixuser 2147491841 - Ephemeral mapping winuser Administrator@example.com S-1-5-21-3591674789-480817656-4239000414-500 -> unixuser 2147491841 - Done COMMENTS Implementation note: It is trivial to add or remove these trace points and easy to add additional data to be recorded. It is also possible to configure the tool so that all mappings (not just idmap show requests) will yield trace output, with the output directed to the SMF service log. However, those debug mechanisms are as yet private. DELIVERY VEHICLE Solaris RELEASE Patch COMMITMENT LEVEL -V option Uncommitted Trace points reported Not-an-interface Output format Not-an-interface Data reported Not-an-interface In other words, what is committed is that idmap show -V will produce some sort of human-readable trace output, but nothing of that output is committed. 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open From Jordan.Brown@oracle.com Wed Apr 14 14:39:16 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o3ELdGca004851 for ; Wed, 14 Apr 2010 14:39:16 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o3ELdG9D042735 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 14 Apr 2010 15:39:16 -0600 (MDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L0V00G03YTG8T00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 14 Apr 2010 15:39:16 -0600 (MDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L0V00JLEYTEPCB0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 14 Apr 2010 15:39:14 -0600 (MDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o3ELdEd9028178 for ; Wed, 14 Apr 2010 21:39:14 +0000 (GMT) Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o3ELRlof011200 for ; Wed, 14 Apr 2010 21:39:14 +0000 (GMT) Received: from abhmt019.oracle.com by acsmt354.oracle.com with ESMTP id 161306931271281140; Wed, 14 Apr 2010 14:39:00 -0700 Received: from [129.145.155.152] (/129.145.155.152) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 14 Apr 2010 14:39:00 -0700 Date: Wed, 14 Apr 2010 14:38:58 -0700 From: Jordan Brown Subject: Re: idmap show -V mapping trace mechanism [PSARC/2010/125 FastTrack timeout 04/16/2010] In-reply-to: <201004092146.o39LkJ50015410@sac.sfbay.sun.com> To: Jordan Brown Cc: PSARC-ext@sun.com, smb-eng_ww@oracle.com, winchester@sun.com Message-id: <4BC635F2.3040806@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090203.4BC63602.00A4:SCFMA4539814,ss=1,fgs=0 References: <201004092146.o39LkJ50015410@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.14 (X11/20080505) Status: RO Content-Length: 3716 Can I get a +1, please? Jordan Brown wrote: > Template Version: @(#)sac_nextcase 1.70 03/30/10 SMI > This information is Copyright (c) 2010, Oracle and/or its affiliates. All rights reserved. > 1. Introduction > 1.1. Project/Component Working Name: > idmap show -V mapping trace mechanism > 1.2. Name of Document Author/Supplier: > Author: Jordan Brown > 1.3 Date of This Document: > 09 April, 2010 > 4. Technical Description > > SUMMARY > > Provide a mechanism whereby an administrator can examine in > detail the steps used to map a Windows identity to a UNIX > identity, or vice versa. > > BACKGROUND > > The idmap subsystem provides a mechanism to map Windows > identities to UNIX identities, and vice versa, using a mixture > of hardcoded data, rules, directory-based information, and > algorithms. The "idmap show" command allows the administrator > to determine the mapping resulting for any given input identity > and to determine the mapping mechanism finally used, but does > not reveal, for instance, why other mapping mechanisms were not > chosen. > > PROBLEM > > Existing tools do not provide enough information to enable > easily diagnosing why a particular mapping does not yield the > expected result. > > PROPOSAL > > When requested using "idmap show -V", during each step of the > processing of a mapping, record the state of the mapping > process and a message describing the results of the particular > step. Provide this recorded data as part of the output from > the command. > > DETAILS > > Add a new "-V" option to idmap show. When specified, this > option causes all significant decision points in the processing > to be recorded and, on completion of the request, reported to > the user. > > Sample output: > > $ idmap show -cV administrator@example.com > winuser:administrator@example.com -> uid:2147491841 > Trace: > winname administrator@example.com -> unknown - Start mapping > winname administrator@example.com -> unixname - Not a well-known account > winname administrator@example.com -> unixname - Not a local SID > winname administrator@example.com -> unixname - Not found in mapping cache > winname administrator@example.com -> unixname - Not found in name cache > winuser Administrator@example.com S-1-5-21-3591674789-480817656-4239000414-500 -> unixuser - AD lookup > winuser Administrator@example.com S-1-5-21-3591674789-480817656-4239000414-500 -> unixuser - No matching rule > winuser Administrator@example.com S-1-5-21-3591674789-480817656-4239000414-500 -> unixuser 2147491841 - Ephemeral mapping > winuser Administrator@example.com S-1-5-21-3591674789-480817656-4239000414-500 -> unixuser 2147491841 - Done > > COMMENTS > > Implementation note: It is trivial to add or remove these > trace points and easy to add additional data to be recorded. > > It is also possible to configure the tool so that all mappings > (not just idmap show requests) will yield trace output, with > the output directed to the SMF service log. However, those > debug mechanisms are as yet private. > > DELIVERY VEHICLE > > Solaris > > RELEASE > > Patch > > COMMITMENT LEVEL > > -V option Uncommitted > Trace points reported Not-an-interface > Output format Not-an-interface > Data reported Not-an-interface > > In other words, what is committed is that idmap show -V will > produce some sort of human-readable trace output, but nothing of > that output is committed. > > 6. Resources and Schedule > 6.4. Steering Committee requested information > 6.4.1. Consolidation C-team Name: > ON > 6.5. ARC review type: FastTrack > 6.6. ARC Exposure: open > > From Jordan.Brown@oracle.com Wed Apr 14 14:39:17 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o3ELdG4w004855 for ; Wed, 14 Apr 2010 14:39:17 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o3ELdGgd042742 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 14 Apr 2010 15:39:16 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L0V00F0LYTG8P00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 14 Apr 2010 14:39:16 -0700 (PDT) Received: from sca-ea-mail-2.sun.com ([192.18.43.25]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L0V001YIYTGTZA0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 14 Apr 2010 14:39:16 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o3ELdFq1011566 for ; Wed, 14 Apr 2010 21:39:16 +0000 (GMT) Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o3ELRloh011200 for ; Wed, 14 Apr 2010 21:39:15 +0000 (GMT) Received: from abhmt019.oracle.com by acsmt354.oracle.com with ESMTP id 161306931271281140; Wed, 14 Apr 2010 14:39:00 -0700 Received: from [129.145.155.152] (/129.145.155.152) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 14 Apr 2010 14:39:00 -0700 Date: Wed, 14 Apr 2010 14:38:58 -0700 From: Jordan Brown Subject: Re: idmap show -V mapping trace mechanism [PSARC/2010/125 FastTrack timeout 04/16/2010] In-reply-to: <201004092146.o39LkJ50015410@sac.sfbay.sun.com> To: Jordan Brown Cc: PSARC-ext@sun.com, smb-eng_ww@oracle.com, winchester@sun.com Message-id: <4BC635F2.3040806@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090204.4BC63603.0138:SCFMA4539814,ss=1,fgs=0 References: <201004092146.o39LkJ50015410@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.14 (X11/20080505) Status: RO Content-Length: 3716 Can I get a +1, please? Jordan Brown wrote: > Template Version: @(#)sac_nextcase 1.70 03/30/10 SMI > This information is Copyright (c) 2010, Oracle and/or its affiliates. All rights reserved. > 1. Introduction > 1.1. Project/Component Working Name: > idmap show -V mapping trace mechanism > 1.2. Name of Document Author/Supplier: > Author: Jordan Brown > 1.3 Date of This Document: > 09 April, 2010 > 4. Technical Description > > SUMMARY > > Provide a mechanism whereby an administrator can examine in > detail the steps used to map a Windows identity to a UNIX > identity, or vice versa. > > BACKGROUND > > The idmap subsystem provides a mechanism to map Windows > identities to UNIX identities, and vice versa, using a mixture > of hardcoded data, rules, directory-based information, and > algorithms. The "idmap show" command allows the administrator > to determine the mapping resulting for any given input identity > and to determine the mapping mechanism finally used, but does > not reveal, for instance, why other mapping mechanisms were not > chosen. > > PROBLEM > > Existing tools do not provide enough information to enable > easily diagnosing why a particular mapping does not yield the > expected result. > > PROPOSAL > > When requested using "idmap show -V", during each step of the > processing of a mapping, record the state of the mapping > process and a message describing the results of the particular > step. Provide this recorded data as part of the output from > the command. > > DETAILS > > Add a new "-V" option to idmap show. When specified, this > option causes all significant decision points in the processing > to be recorded and, on completion of the request, reported to > the user. > > Sample output: > > $ idmap show -cV administrator@example.com > winuser:administrator@example.com -> uid:2147491841 > Trace: > winname administrator@example.com -> unknown - Start mapping > winname administrator@example.com -> unixname - Not a well-known account > winname administrator@example.com -> unixname - Not a local SID > winname administrator@example.com -> unixname - Not found in mapping cache > winname administrator@example.com -> unixname - Not found in name cache > winuser Administrator@example.com S-1-5-21-3591674789-480817656-4239000414-500 -> unixuser - AD lookup > winuser Administrator@example.com S-1-5-21-3591674789-480817656-4239000414-500 -> unixuser - No matching rule > winuser Administrator@example.com S-1-5-21-3591674789-480817656-4239000414-500 -> unixuser 2147491841 - Ephemeral mapping > winuser Administrator@example.com S-1-5-21-3591674789-480817656-4239000414-500 -> unixuser 2147491841 - Done > > COMMENTS > > Implementation note: It is trivial to add or remove these > trace points and easy to add additional data to be recorded. > > It is also possible to configure the tool so that all mappings > (not just idmap show requests) will yield trace output, with > the output directed to the SMF service log. However, those > debug mechanisms are as yet private. > > DELIVERY VEHICLE > > Solaris > > RELEASE > > Patch > > COMMITMENT LEVEL > > -V option Uncommitted > Trace points reported Not-an-interface > Output format Not-an-interface > Data reported Not-an-interface > > In other words, what is committed is that idmap show -V will > produce some sort of human-readable trace output, but nothing of > that output is committed. > > 6. Resources and Schedule > 6.4. Steering Committee requested information > 6.4.1. Consolidation C-team Name: > ON > 6.5. ARC review type: FastTrack > 6.6. ARC Exposure: open > > From michael.kearney@oracle.com Fri Apr 16 08:09:43 2010 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o3GF9h1b015320 for ; Fri, 16 Apr 2010 08:09:43 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o3GF9gRf021754 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 16 Apr 2010 08:09:43 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L0Z00217647C200@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 16 Apr 2010 09:09:43 -0600 (MDT) Received: from sca-ea-mail-3.sun.com ([192.18.43.21]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L0Z00MWB646P710@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 16 Apr 2010 09:09:42 -0600 (MDT) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o3GF9f0w013956 for ; Fri, 16 Apr 2010 15:09:41 +0000 (GMT) Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o3GF9bEU019099 for ; Fri, 16 Apr 2010 15:09:40 +0000 (GMT) Received: from abhmt009.oracle.com by acsmt355.oracle.com with ESMTP id 182259441271430576; Fri, 16 Apr 2010 08:09:36 -0700 Received: from [129.147.223.4] (/129.147.223.4) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 16 Apr 2010 08:09:34 -0700 Date: Fri, 16 Apr 2010 09:09:21 -0600 From: Michael Kearney Subject: Re: idmap show -V mapping trace mechanism [PSARC/2010/125 FastTrack timeout 04/16/2010] In-reply-to: <201004092146.o39LkJ50015410@sac.sfbay.sun.com> To: Jordan Brown Cc: PSARC-ext@sun.com, smb-eng_ww@oracle.com, winchester@sun.com Message-id: <4BC87DA1.400@oracle.com> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_nv5BsxK7+NIyLtc7PBgqhw)" X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090203.4BC87DB5.00A0:SCFMA4539814,ss=1,fgs=0 References: <201004092146.o39LkJ50015410@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) Status: RO Content-Length: 11225 This is a multi-part message in MIME format. --Boundary_(ID_nv5BsxK7+NIyLtc7PBgqhw) Content-type: multipart/alternative; boundary="Boundary_(ID_TTz2Awk3bC0Vu6AOIL5ftw)" --Boundary_(ID_TTz2Awk3bC0Vu6AOIL5ftw) Content-type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: 7BIT I note that the show option already has a lowercase -v option. The -v option shows how the mapping was generated and also whether the mapping was just generated or was retrieved from the cache. How are -v and -V different? -Michael On 4/9/2010 3:46 PM, Jordan Brown wrote: > Template Version: @(#)sac_nextcase 1.70 03/30/10 SMI > This information is Copyright (c) 2010, Oracle and/or its affiliates. All rights reserved. > 1. Introduction > 1.1. Project/Component Working Name: > idmap show -V mapping trace mechanism > 1.2. Name of Document Author/Supplier: > Author: Jordan Brown > 1.3 Date of This Document: > 09 April, 2010 > 4. Technical Description > > SUMMARY > > Provide a mechanism whereby an administrator can examine in > detail the steps used to map a Windows identity to a UNIX > identity, or vice versa. > > BACKGROUND > > The idmap subsystem provides a mechanism to map Windows > identities to UNIX identities, and vice versa, using a mixture > of hardcoded data, rules, directory-based information, and > algorithms. The "idmap show" command allows the administrator > to determine the mapping resulting for any given input identity > and to determine the mapping mechanism finally used, but does > not reveal, for instance, why other mapping mechanisms were not > chosen. > > PROBLEM > > Existing tools do not provide enough information to enable > easily diagnosing why a particular mapping does not yield the > expected result. > > PROPOSAL > > When requested using "idmap show -V", during each step of the > processing of a mapping, record the state of the mapping > process and a message describing the results of the particular > step. Provide this recorded data as part of the output from > the command. > > DETAILS > > Add a new "-V" option to idmap show. When specified, this > option causes all significant decision points in the processing > to be recorded and, on completion of the request, reported to > the user. > > Sample output: > > $ idmap show -cV administrator@example.com > winuser:administrator@example.com -> uid:2147491841 > Trace: > winname administrator@example.com -> unknown - Start mapping > winname administrator@example.com -> unixname - Not a well-known account > winname administrator@example.com -> unixname - Not a local SID > winname administrator@example.com -> unixname - Not found in mapping cache > winname administrator@example.com -> unixname - Not found in name cache > winuser Administrator@example.com S-1-5-21-3591674789-480817656-4239000414-500 -> unixuser - AD lookup > winuser Administrator@example.com S-1-5-21-3591674789-480817656-4239000414-500 -> unixuser - No matching rule > winuser Administrator@example.com S-1-5-21-3591674789-480817656-4239000414-500 -> unixuser 2147491841 - Ephemeral mapping > winuser Administrator@example.com S-1-5-21-3591674789-480817656-4239000414-500 -> unixuser 2147491841 - Done > > COMMENTS > > Implementation note: It is trivial to add or remove these > trace points and easy to add additional data to be recorded. > > It is also possible to configure the tool so that all mappings > (not just idmap show requests) will yield trace output, with > the output directed to the SMF service log. However, those > debug mechanisms are as yet private. > > DELIVERY VEHICLE > > Solaris > > RELEASE > > Patch > > COMMITMENT LEVEL > > -V option Uncommitted > Trace points reported Not-an-interface > Output format Not-an-interface > Data reported Not-an-interface > > In other words, what is committed is that idmap show -V will > produce some sort of human-readable trace output, but nothing of > that output is committed. > > 6. Resources and Schedule > 6.4. Steering Committee requested information > 6.4.1. Consolidation C-team Name: > ON > 6.5. ARC review type: FastTrack > 6.6. ARC Exposure: open > > > -- * Michael Kearney * Principal Software Engineer *Oracle Corp.* MS UBRM05-390, 500 Eldorado Blvd Broomfield, CO 80021 US Phone 303-272-2402 Fax 303-272-6554 Email Michael.Kearney@Oracle.COM --Boundary_(ID_TTz2Awk3bC0Vu6AOIL5ftw) Content-type: text/html; charset=UTF-8 Content-transfer-encoding: 8BIT
I note that the show option already has a lowercase -v option.
The -v option shows how the mapping was generated and also
whether the mapping was just generated or was retrieved from the cache.

How are -v and -V different?

       -Michael

On 4/9/2010 3:46 PM, Jordan Brown wrote: 
Template Version: @(#)sac_nextcase 1.70 03/30/10 SMI
This information is Copyright (c) 2010, Oracle and/or its affiliates. All rights reserved.
1. Introduction
    1.1. Project/Component Working Name:
	 idmap show -V mapping trace mechanism
    1.2. Name of Document Author/Supplier:
	 Author:  Jordan Brown
    1.3  Date of This Document:
	09 April, 2010
4. Technical Description

    SUMMARY

	Provide a mechanism whereby an administrator can examine in
	detail the steps used to map a Windows identity to a UNIX
	identity, or vice versa.

    BACKGROUND

	The idmap subsystem provides a mechanism to map Windows
	identities to UNIX identities, and vice versa, using a mixture
	of hardcoded data, rules, directory-based information, and
	algorithms.  The "idmap show" command allows the administrator
	to determine the mapping resulting for any given input identity
	and to determine the mapping mechanism finally used, but does
	not reveal, for instance, why other mapping mechanisms were not
	chosen.

    PROBLEM

	Existing tools do not provide enough information to enable
	easily diagnosing why a particular mapping does not yield the
	expected result.

    PROPOSAL

	When requested using "idmap show -V", during each step of the
	processing of a mapping, record the state of the mapping
	process and a message describing the results of the particular
	step.  Provide this recorded data as part of the output from
	the command.

    DETAILS

	Add a new "-V" option to idmap show.  When specified, this
	option causes all significant decision points in the processing
	to be recorded and, on completion of the request, reported to
	the user.

	Sample output:

	$ idmap show -cV administrator@example.com
	winuser:administrator@example.com -> uid:2147491841
	Trace:
		winname administrator@example.com -> unknown - Start mapping
		winname administrator@example.com -> unixname - Not a well-known account
		winname administrator@example.com -> unixname - Not a local SID
		winname administrator@example.com -> unixname - Not found in mapping cache
		winname administrator@example.com -> unixname - Not found in name cache
		winuser Administrator@example.com S-1-5-21-3591674789-480817656-4239000414-500 -> unixuser - AD lookup
		winuser Administrator@example.com S-1-5-21-3591674789-480817656-4239000414-500 -> unixuser - No matching rule
		winuser Administrator@example.com S-1-5-21-3591674789-480817656-4239000414-500 -> unixuser 2147491841 - Ephemeral mapping
		winuser Administrator@example.com S-1-5-21-3591674789-480817656-4239000414-500 -> unixuser 2147491841 - Done

    COMMENTS

	Implementation note:  It is trivial to add or remove these
	trace points and easy to add additional data to be recorded.

	It is also possible to configure the tool so that all mappings
	(not just idmap show requests) will yield trace output, with
	the output directed to the SMF service log.  However, those
	debug mechanisms are as yet private.

    DELIVERY VEHICLE

	Solaris

    RELEASE

	Patch

    COMMITMENT LEVEL

	-V option		Uncommitted
	Trace points reported	Not-an-interface
	Output format		Not-an-interface
	Data reported		Not-an-interface

	In other words, what is committed is that idmap show -V will
	produce some sort of human-readable trace output, but nothing of
	that output is committed.

6. Resources and Schedule
    6.4. Steering Committee requested information
   	6.4.1. Consolidation C-team Name:
		ON
    6.5. ARC review type: FastTrack
    6.6. ARC Exposure: open

--
Michael Kearney
Principal Software Engineer

Oracle Corp.
MS UBRM05-390, 500 Eldorado Blvd
Broomfield, CO 80021 US
Phone 303-272-2402
Fax 303-272-6554
Email Michael.Kearney@Oracle.COM
--Boundary_(ID_TTz2Awk3bC0Vu6AOIL5ftw)-- --Boundary_(ID_nv5BsxK7+NIyLtc7PBgqhw) Content-type: text/x-vcard; charset=utf-8; name=michael_kearney.vcf Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=michael_kearney.vcf begin:vcard fn:Michael Kearney n:Kearney;Michael org:VTCS Enterprise Engineering;Tikka adr:;;500 Eldorado Blvd;Broomfield;CO;80021;USA email;internet:michael.kearney@oracle.com title:Principal Software Engineer tel;work:303-272-2402 url:http://www.oracle.com version:2.1 end:vcard --Boundary_(ID_nv5BsxK7+NIyLtc7PBgqhw)-- From michael.kearney@oracle.com Fri Apr 16 08:09:45 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o3GF9jfF015324 for ; Fri, 16 Apr 2010 08:09:45 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o3GF9e3k004360 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 16 Apr 2010 09:09:45 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L0Z00L3F648FL00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 16 Apr 2010 08:09:44 -0700 (PDT) Received: from sca-ea-mail-2.sun.com ([192.18.43.25]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L0Z00BJ46476680@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 16 Apr 2010 08:09:43 -0700 (PDT) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o3GF9gnw026275 for ; Fri, 16 Apr 2010 15:09:43 +0000 (GMT) Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o3GF9bEW019099 for ; Fri, 16 Apr 2010 15:09:42 +0000 (GMT) Received: from abhmt009.oracle.com by acsmt355.oracle.com with ESMTP id 182259441271430576; Fri, 16 Apr 2010 08:09:36 -0700 Received: from [129.147.223.4] (/129.147.223.4) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 16 Apr 2010 08:09:34 -0700 Date: Fri, 16 Apr 2010 09:09:21 -0600 From: Michael Kearney Subject: Re: idmap show -V mapping trace mechanism [PSARC/2010/125 FastTrack timeout 04/16/2010] In-reply-to: <201004092146.o39LkJ50015410@sac.sfbay.sun.com> To: Jordan Brown Cc: PSARC-ext@sun.com, smb-eng_ww@oracle.com, winchester@sun.com Message-id: <4BC87DA1.400@oracle.com> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_yeYsA5tKQQzKrKj4xdv7jA)" X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090205.4BC87DB6.00DC:SCFMA4539814,ss=1,fgs=0 References: <201004092146.o39LkJ50015410@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) Status: RO Content-Length: 11225 This is a multi-part message in MIME format. --Boundary_(ID_yeYsA5tKQQzKrKj4xdv7jA) Content-type: multipart/alternative; boundary="Boundary_(ID_1/8yNyq1300ZJH348Kum+g)" --Boundary_(ID_1/8yNyq1300ZJH348Kum+g) Content-type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: 7BIT I note that the show option already has a lowercase -v option. The -v option shows how the mapping was generated and also whether the mapping was just generated or was retrieved from the cache. How are -v and -V different? -Michael On 4/9/2010 3:46 PM, Jordan Brown wrote: > Template Version: @(#)sac_nextcase 1.70 03/30/10 SMI > This information is Copyright (c) 2010, Oracle and/or its affiliates. All rights reserved. > 1. Introduction > 1.1. Project/Component Working Name: > idmap show -V mapping trace mechanism > 1.2. Name of Document Author/Supplier: > Author: Jordan Brown > 1.3 Date of This Document: > 09 April, 2010 > 4. Technical Description > > SUMMARY > > Provide a mechanism whereby an administrator can examine in > detail the steps used to map a Windows identity to a UNIX > identity, or vice versa. > > BACKGROUND > > The idmap subsystem provides a mechanism to map Windows > identities to UNIX identities, and vice versa, using a mixture > of hardcoded data, rules, directory-based information, and > algorithms. The "idmap show" command allows the administrator > to determine the mapping resulting for any given input identity > and to determine the mapping mechanism finally used, but does > not reveal, for instance, why other mapping mechanisms were not > chosen. > > PROBLEM > > Existing tools do not provide enough information to enable > easily diagnosing why a particular mapping does not yield the > expected result. > > PROPOSAL > > When requested using "idmap show -V", during each step of the > processing of a mapping, record the state of the mapping > process and a message describing the results of the particular > step. Provide this recorded data as part of the output from > the command. > > DETAILS > > Add a new "-V" option to idmap show. When specified, this > option causes all significant decision points in the processing > to be recorded and, on completion of the request, reported to > the user. > > Sample output: > > $ idmap show -cV administrator@example.com > winuser:administrator@example.com -> uid:2147491841 > Trace: > winname administrator@example.com -> unknown - Start mapping > winname administrator@example.com -> unixname - Not a well-known account > winname administrator@example.com -> unixname - Not a local SID > winname administrator@example.com -> unixname - Not found in mapping cache > winname administrator@example.com -> unixname - Not found in name cache > winuser Administrator@example.com S-1-5-21-3591674789-480817656-4239000414-500 -> unixuser - AD lookup > winuser Administrator@example.com S-1-5-21-3591674789-480817656-4239000414-500 -> unixuser - No matching rule > winuser Administrator@example.com S-1-5-21-3591674789-480817656-4239000414-500 -> unixuser 2147491841 - Ephemeral mapping > winuser Administrator@example.com S-1-5-21-3591674789-480817656-4239000414-500 -> unixuser 2147491841 - Done > > COMMENTS > > Implementation note: It is trivial to add or remove these > trace points and easy to add additional data to be recorded. > > It is also possible to configure the tool so that all mappings > (not just idmap show requests) will yield trace output, with > the output directed to the SMF service log. However, those > debug mechanisms are as yet private. > > DELIVERY VEHICLE > > Solaris > > RELEASE > > Patch > > COMMITMENT LEVEL > > -V option Uncommitted > Trace points reported Not-an-interface > Output format Not-an-interface > Data reported Not-an-interface > > In other words, what is committed is that idmap show -V will > produce some sort of human-readable trace output, but nothing of > that output is committed. > > 6. Resources and Schedule > 6.4. Steering Committee requested information > 6.4.1. Consolidation C-team Name: > ON > 6.5. ARC review type: FastTrack > 6.6. ARC Exposure: open > > > -- * Michael Kearney * Principal Software Engineer *Oracle Corp.* MS UBRM05-390, 500 Eldorado Blvd Broomfield, CO 80021 US Phone 303-272-2402 Fax 303-272-6554 Email Michael.Kearney@Oracle.COM --Boundary_(ID_1/8yNyq1300ZJH348Kum+g) Content-type: text/html; charset=UTF-8 Content-transfer-encoding: 8BIT
I note that the show option already has a lowercase -v option.
The -v option shows how the mapping was generated and also
whether the mapping was just generated or was retrieved from the cache.

How are -v and -V different?

       -Michael

On 4/9/2010 3:46 PM, Jordan Brown wrote: 
Template Version: @(#)sac_nextcase 1.70 03/30/10 SMI
This information is Copyright (c) 2010, Oracle and/or its affiliates. All rights reserved.
1. Introduction
    1.1. Project/Component Working Name:
	 idmap show -V mapping trace mechanism
    1.2. Name of Document Author/Supplier:
	 Author:  Jordan Brown
    1.3  Date of This Document:
	09 April, 2010
4. Technical Description

    SUMMARY

	Provide a mechanism whereby an administrator can examine in
	detail the steps used to map a Windows identity to a UNIX
	identity, or vice versa.

    BACKGROUND

	The idmap subsystem provides a mechanism to map Windows
	identities to UNIX identities, and vice versa, using a mixture
	of hardcoded data, rules, directory-based information, and
	algorithms.  The "idmap show" command allows the administrator
	to determine the mapping resulting for any given input identity
	and to determine the mapping mechanism finally used, but does
	not reveal, for instance, why other mapping mechanisms were not
	chosen.

    PROBLEM

	Existing tools do not provide enough information to enable
	easily diagnosing why a particular mapping does not yield the
	expected result.

    PROPOSAL

	When requested using "idmap show -V", during each step of the
	processing of a mapping, record the state of the mapping
	process and a message describing the results of the particular
	step.  Provide this recorded data as part of the output from
	the command.

    DETAILS

	Add a new "-V" option to idmap show.  When specified, this
	option causes all significant decision points in the processing
	to be recorded and, on completion of the request, reported to
	the user.

	Sample output:

	$ idmap show -cV administrator@example.com
	winuser:administrator@example.com -> uid:2147491841
	Trace:
		winname administrator@example.com -> unknown - Start mapping
		winname administrator@example.com -> unixname - Not a well-known account
		winname administrator@example.com -> unixname - Not a local SID
		winname administrator@example.com -> unixname - Not found in mapping cache
		winname administrator@example.com -> unixname - Not found in name cache
		winuser Administrator@example.com S-1-5-21-3591674789-480817656-4239000414-500 -> unixuser - AD lookup
		winuser Administrator@example.com S-1-5-21-3591674789-480817656-4239000414-500 -> unixuser - No matching rule
		winuser Administrator@example.com S-1-5-21-3591674789-480817656-4239000414-500 -> unixuser 2147491841 - Ephemeral mapping
		winuser Administrator@example.com S-1-5-21-3591674789-480817656-4239000414-500 -> unixuser 2147491841 - Done

    COMMENTS

	Implementation note:  It is trivial to add or remove these
	trace points and easy to add additional data to be recorded.

	It is also possible to configure the tool so that all mappings
	(not just idmap show requests) will yield trace output, with
	the output directed to the SMF service log.  However, those
	debug mechanisms are as yet private.

    DELIVERY VEHICLE

	Solaris

    RELEASE

	Patch

    COMMITMENT LEVEL

	-V option		Uncommitted
	Trace points reported	Not-an-interface
	Output format		Not-an-interface
	Data reported		Not-an-interface

	In other words, what is committed is that idmap show -V will
	produce some sort of human-readable trace output, but nothing of
	that output is committed.

6. Resources and Schedule
    6.4. Steering Committee requested information
   	6.4.1. Consolidation C-team Name:
		ON
    6.5. ARC review type: FastTrack
    6.6. ARC Exposure: open

--
Michael Kearney
Principal Software Engineer

Oracle Corp.
MS UBRM05-390, 500 Eldorado Blvd
Broomfield, CO 80021 US
Phone 303-272-2402
Fax 303-272-6554
Email Michael.Kearney@Oracle.COM
--Boundary_(ID_1/8yNyq1300ZJH348Kum+g)-- --Boundary_(ID_yeYsA5tKQQzKrKj4xdv7jA) Content-type: text/x-vcard; charset=utf-8; name=michael_kearney.vcf Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=michael_kearney.vcf begin:vcard fn:Michael Kearney n:Kearney;Michael org:VTCS Enterprise Engineering;Tikka adr:;;500 Eldorado Blvd;Broomfield;CO;80021;USA email;internet:michael.kearney@oracle.com title:Principal Software Engineer tel;work:303-272-2402 url:http://www.oracle.com version:2.1 end:vcard --Boundary_(ID_yeYsA5tKQQzKrKj4xdv7jA)-- From Jordan.Brown@oracle.com Fri Apr 16 09:37:16 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o3GGbGXj016675 for ; Fri, 16 Apr 2010 09:37:16 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o3GGbGrT004471 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 16 Apr 2010 10:37:16 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L0Z00I01A63K400@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 16 Apr 2010 09:37:15 -0700 (PDT) Received: from sca-ea-mail-3.sun.com ([192.18.43.21]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L0Z00E63A63HT40@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 16 Apr 2010 09:37:15 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o3GGbFBR018791 for ; Fri, 16 Apr 2010 16:37:15 +0000 (GMT) Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o3G1TsDW029570 for ; Fri, 16 Apr 2010 16:37:14 +0000 (GMT) Received: from abhmt016.oracle.com by acsmt355.oracle.com with ESMTP id 166630221271435778; Fri, 16 Apr 2010 09:36:18 -0700 Received: from [129.145.155.152] (/129.145.155.152) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 16 Apr 2010 09:36:17 -0700 Date: Fri, 16 Apr 2010 09:36:16 -0700 From: Jordan Brown Subject: Re: idmap show -V mapping trace mechanism [PSARC/2010/125 FastTrack timeout 04/16/2010] In-reply-to: <4BC87DA1.400@oracle.com> To: Michael Kearney Cc: PSARC-ext@sun.com Message-id: <4BC89200.5050404@oracle.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_+lmCX3cXvIEwcuDNZSgeWg)" X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A0B0203.4BC8923A.015C:SCFMA4539814,ss=1,fgs=0 References: <201004092146.o39LkJ50015410@sac.sfbay.sun.com> <4BC87DA1.400@oracle.com> User-Agent: Thunderbird 2.0.0.14 (X11/20080505) Status: RO Content-Length: 16915 This is a multi-part message in MIME format. --Boundary_(ID_+lmCX3cXvIEwcuDNZSgeWg) Content-type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: 7BIT [ You'll probably want a wide window to view the output lines here. I could probably have the program break them up a bit, but some of the data fields are pretty long and might wrap anyway, and it's not clear that multiline entries would be more readable. ] Michael Kearney wrote: > I note that the show option already has a lowercase -v option. > The -v option shows how the mapping was generated and also > whether the mapping was just generated or was retrieved from the cache. > > How are -v and -V different? -v reports the _one_ mechanism chosen and some data about it. It does not report the other mechanisms attempted, or the possibly convoluted path that led from the input to the output. While it's helpful, it has proven inadequate. For instance, given a Windows user jordan@example.com and a mapping rule $ idmap list add winname:jordan@example.com unixuser:badunix idmap show -cv says: $ idmap show -cv jordan@example.com winuser:jordan@example.com -> uid:60001 Error: Mapping not found or inhibited Failed Method: Name Rule Rule: add winname:jordan@example.com unixuser:badunix That's actually not too bad; although it doesn't point straight at the problem, it at least reports the name that couldn't be found. -V, on the other hand, documents each step in the mapping process. idmap show -cV says the following. (Note that since it's an error case you get the "-v" output for free.) $ idmap show -cV jordan@example.com winuser:jordan@example.com -> uid:60001 Error: Mapping not found or inhibited Failed Method: Name Rule Rule: add winname:jordan@example.com unixuser:badunix winname jordan@example.com -> unknown - Start mapping winname jordan@example.com -> unixname - Not a well-known account winname jordan@example.com -> unixname - Not a local SID winname jordan@example.com -> unixname - Not found in mapping cache winname jordan@example.com -> unixname - Not found in name cache winuser jordan@example.com S-1-5-21-3591674789-480817656-4239000414-1106 -> unixuser - AD lookup winuser jordan@example.com S-1-5-21-3591674789-480817656-4239000414-1106 -> unixuser - Matching rule: jordan@example.com -> badunix winuser jordan@example.com S-1-5-21-3591674789-480817656-4239000414-1106 -> unixuser - badunix not found, error winuser jordan@example.com S-1-5-21-3591674789-480817656-4239000414-1106 -> unixuser - Rule-based mapping error=-9981 winuser jordan@example.com S-1-5-21-3591674789-480817656-4239000414-1106 -> unixuser 60001 Error -9981 - Done Here's a more subtle case. Given this rule: $ idmap list add winname:*@example.com unixuser:* $ idmap show -cv jordan@example.com winuser:jordan@example.com -> uid:2147516418 Source: New Method: Ephemeral Note that -v doesn't tell us why we ended up with an Ephemeral mapping instead of using the rule. $ idmap show -cV jordan@example.com winuser:jordan@example.com -> uid:2147516419 [[ BTW: it's a different ephemeral ID because I wiped the cache between the two examples ]] Trace: winname jordan@example.com -> unknown - Start mapping winname jordan@example.com -> unixname - Not a well-known account winname jordan@example.com -> unixname - Not a local SID winname jordan@example.com -> unixname - Not found in mapping cache winname jordan@example.com -> unixname - Not found in name cache winuser jordan@example.com S-1-5-21-3591674789-480817656-4239000414-1106 -> unixuser - AD lookup winuser jordan@example.com S-1-5-21-3591674789-480817656-4239000414-1106 -> unixuser - Matching rule: *@example.com -> * winuser jordan@example.com S-1-5-21-3591674789-480817656-4239000414-1106 -> unixuser - jordan not found, continuing winuser jordan@example.com S-1-5-21-3591674789-480817656-4239000414-1106 -> unixuser - No matching rule winuser jordan@example.com S-1-5-21-3591674789-480817656-4239000414-1106 -> unixuser 2147516419 - Ephemeral mapping winuser jordan@example.com S-1-5-21-3591674789-480817656-4239000414-1106 -> unixuser 2147516419 - Done While my hypothetical Windows username is "jordan", my UNIX username is "jb25718", and so the wild-card rule couldn't be used. (A variation on this is a real customer case; their name service wasn't set up right and UNIX users weren't getting looked up properly.) Or suppose I've transcribed my SID incorrectly (and unresolvable SID mapping is enabled, as it is by default these days): $ idmap list add winname:jordan@a.jb25718.west.sun.com unixuser:jb25718 $ idmap show -cv sid:S-1-5-21-3591674780-480817656-4239000414-1106 unixuser usid:S-1-5-21-3591674780-480817656-4239000414-1106 -> uid:2147516421 Source: New Method: Ephemeral $ idmap show -cV sid:S-1-5-21-3591674780-480817656-4239000414-1106 unixuser usid:S-1-5-21-3591674780-480817656-4239000414-1106 -> uid:2147516422 Trace: winname S-1-5-21-3591674780-480817656-4239000414-1106 -> unknown - Start mapping winname S-1-5-21-3591674780-480817656-4239000414-1106 -> unixuser - Not a well-known account winname S-1-5-21-3591674780-480817656-4239000414-1106 -> unixuser - Not a local SID winname S-1-5-21-3591674780-480817656-4239000414-1106 -> unixuser - Not found in mapping cache winname S-1-5-21-3591674780-480817656-4239000414-1106 -> unixuser - Not found in name cache winname S-1-5-21-3591674780-480817656-4239000414-1106 -> unixuser Error -9976 - AD lookup winuser S-1-5-21-3591674780-480817656-4239000414-1106 -> unixuser Error -9976 - Must map unresolvable SID to user winuser S-1-5-21-3591674780-480817656-4239000414-1106 -> unixuser 2147516422 Error -9976 - Ephemeral mapping winuser S-1-5-21-3591674780-480817656-4239000414-1106 -> unixuser 2147516422 - Done The idea is that -V doesn't just document the result; it documents each piece of information, where it came from, and what decisions were made based on that data. --Boundary_(ID_+lmCX3cXvIEwcuDNZSgeWg) Content-type: text/html; charset=UTF-8 Content-transfer-encoding: 8BIT [ You'll probably want a wide window to view the output lines here.  I could probably have the program break them up a bit, but some of the data fields are pretty long and might wrap anyway, and it's not clear that multiline entries would be more readable. ]

Michael Kearney wrote:
I note that the show option already has a lowercase -v option.
The -v option shows how the mapping was generated and also
whether the mapping was just generated or was retrieved from the cache.

How are -v and -V different?

-v reports the _one_ mechanism chosen and some data about it.  It does not report the other mechanisms attempted, or the possibly convoluted path that led from the input to the output.  While it's helpful, it has proven inadequate.

For instance, given a Windows user jordan@example.com and a mapping rule
    $ idmap list
    add     winname:jordan@example.com   unixuser:badunix

idmap show -cv says:
    $ idmap show -cv jordan@example.com
    winuser:jordan@example.com -> uid:60001
    Error:  Mapping not found or inhibited
    Failed Method:  Name Rule
    Rule:   add     winname:jordan@example.com   unixuser:badunix

That's actually not too bad; although it doesn't point straight at the problem, it at least reports the name that couldn't be found.

-V, on the other hand, documents each step in the mapping process.  idmap show -cV says the following.  (Note that since it's an error case you get the "-v" output for free.)

    $ idmap show -cV jordan@example.com
    winuser:jordan@example.com -> uid:60001
    Error:  Mapping not found or inhibited
    Failed Method:  Name Rule
    Rule:   add     winname:jordan@example.com   unixuser:badunix
        winname jordan@example.com -> unknown - Start mapping
        winname jordan@example.com -> unixname - Not a well-known account
        winname jordan@example.com -> unixname - Not a local SID
        winname jordan@example.com -> unixname - Not found in mapping cache
        winname jordan@example.com -> unixname - Not found in name cache
        winuser jordan@example.com S-1-5-21-3591674789-480817656-4239000414-1106 -> unixuser - AD lookup
        winuser jordan@example.com S-1-5-21-3591674789-480817656-4239000414-1106 -> unixuser - Matching rule: jordan@example.com -> badunix
        winuser jordan@example.com S-1-5-21-3591674789-480817656-4239000414-1106 -> unixuser - badunix not found, error
        winuser jordan@example.com S-1-5-21-3591674789-480817656-4239000414-1106 -> unixuser - Rule-based mapping error=-9981
        winuser jordan@example.com S-1-5-21-3591674789-480817656-4239000414-1106 -> unixuser 60001 Error -9981 - Done


Here's a more subtle case.  Given this rule:

    $ idmap list
    add     winname:*@example.com        unixuser:*

    $ idmap show -cv jordan@example.com
    winuser:jordan@example.com -> uid:2147516418
    Source: New
    Method: Ephemeral

Note that -v doesn't tell us why we ended up with an Ephemeral mapping instead of using the rule.

    $ idmap show -cV jordan@example.com
    winuser:jordan@example.com -> uid:2147516419
          [[ BTW:  it's a different ephemeral ID because I wiped the cache between the two examples ]]
    Trace:
            winname jordan@example.com -> unknown - Start mapping
            winname jordan@example.com -> unixname - Not a well-known account
            winname jordan@example.com -> unixname - Not a local SID
            winname jordan@example.com -> unixname - Not found in mapping cache
            winname jordan@example.com -> unixname - Not found in name cache
            winuser jordan@example.com S-1-5-21-3591674789-480817656-4239000414-1106 -> unixuser - AD lookup
            winuser jordan@example.com S-1-5-21-3591674789-480817656-4239000414-1106 -> unixuser - Matching rule:     *@example.com -> *
            winuser jordan@example.com S-1-5-21-3591674789-480817656-4239000414-1106 -> unixuser - jordan not found, continuing
            winuser jordan@example.com S-1-5-21-3591674789-480817656-4239000414-1106 -> unixuser - No matching rule
            winuser jordan@example.com S-1-5-21-3591674789-480817656-4239000414-1106 -> unixuser 2147516419 - Ephemeral     mapping
            winuser jordan@example.com S-1-5-21-3591674789-480817656-4239000414-1106 -> unixuser 2147516419 - Done

While my hypothetical Windows username is "jordan", my UNIX username is "jb25718", and so the wild-card rule couldn't be used.    (A variation on this is a real customer case; their name service wasn't set up right and UNIX users weren't getting looked up properly.)

Or suppose I've transcribed my SID incorrectly (and unresolvable SID mapping is enabled, as it is by default these days):

    $ idmap list
    add     winname:jordan@a.jb25718.west.sun.com   unixuser:jb25718

    $ idmap show -cv sid:S-1-5-21-3591674780-480817656-4239000414-1106 unixuser
    usid:S-1-5-21-3591674780-480817656-4239000414-1106 -> uid:2147516421
    Source: New
    Method: Ephemeral

    $ idmap show -cV sid:S-1-5-21-3591674780-480817656-4239000414-1106 unixuser
    usid:S-1-5-21-3591674780-480817656-4239000414-1106 -> uid:2147516422
    Trace:
            winname S-1-5-21-3591674780-480817656-4239000414-1106 -> unknown - Start mapping
            winname S-1-5-21-3591674780-480817656-4239000414-1106 -> unixuser - Not a well-known account
            winname S-1-5-21-3591674780-480817656-4239000414-1106 -> unixuser - Not a local SID
            winname S-1-5-21-3591674780-480817656-4239000414-1106 -> unixuser - Not found in mapping cache
            winname S-1-5-21-3591674780-480817656-4239000414-1106 -> unixuser - Not found in name cache
            winname S-1-5-21-3591674780-480817656-4239000414-1106 -> unixuser Error -9976 - AD lookup
            winuser S-1-5-21-3591674780-480817656-4239000414-1106 -> unixuser Error -9976 - Must map unresolvable SID to user
            winuser S-1-5-21-3591674780-480817656-4239000414-1106 -> unixuser 2147516422 Error -9976 - Ephemeral mapping
            winuser S-1-5-21-3591674780-480817656-4239000414-1106 -> unixuser 2147516422 - Done

The idea is that -V doesn't just document the result; it documents each piece of information, where it came from, and what decisions were made based on that data.

--Boundary_(ID_+lmCX3cXvIEwcuDNZSgeWg)-- From michael.kearney@oracle.com Fri Apr 16 09:39:23 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o3GGdN1t016723 for ; Fri, 16 Apr 2010 09:39:23 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o3GGdMre004323 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 16 Apr 2010 11:39:23 -0500 (CDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L0Z00M0DA9MBV00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 16 Apr 2010 09:39:22 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L0Z00B2YA9L69E0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 16 Apr 2010 09:39:22 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o3GGdLbU019739 for ; Fri, 16 Apr 2010 16:39:21 +0000 (GMT) Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o3GCtvP3022182 for ; Fri, 16 Apr 2010 16:39:19 +0000 (GMT) Received: from abhmt021.oracle.com by acsmt355.oracle.com with ESMTP id 182576781271435946; Fri, 16 Apr 2010 09:39:06 -0700 Received: from [129.147.223.4] (/129.147.223.4) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 16 Apr 2010 09:39:06 -0700 Date: Fri, 16 Apr 2010 10:38:52 -0600 From: Michael Kearney Subject: Re: idmap show -V mapping trace mechanism [PSARC/2010/125 FastTrack timeout 04/16/2010] In-reply-to: <4BC89200.5050404@oracle.com> To: Jordan Brown Cc: PSARC-ext@sun.com Message-id: <4BC8929C.6010106@oracle.com> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_fAeaccvvuHSYO3drpwfeZA)" X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A0B0202.4BC892B9.0019:SCFMA4539814,ss=1,fgs=0 References: <201004092146.o39LkJ50015410@sac.sfbay.sun.com> <4BC87DA1.400@oracle.com> <4BC89200.5050404@oracle.com> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) Status: RO Content-Length: 20431 This is a multi-part message in MIME format. --Boundary_(ID_fAeaccvvuHSYO3drpwfeZA) Content-type: multipart/alternative; boundary="Boundary_(ID_jgsjB9PnDILAWs5isJpjLA)" --Boundary_(ID_jgsjB9PnDILAWs5isJpjLA) Content-type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: 7BIT +1 Thank you for the explanation. Regards, Michael On 4/16/2010 10:36 AM, Jordan Brown wrote: > [ You'll probably want a wide window to view the output lines here. I > could probably have the program break them up a bit, but some of the > data fields are pretty long and might wrap anyway, and it's not clear > that multiline entries would be more readable. ] > > Michael Kearney wrote: >> I note that the show option already has a lowercase -v option. >> The -v option shows how the mapping was generated and also >> whether the mapping was just generated or was retrieved from the cache. >> >> How are -v and -V different? > > -v reports the _one_ mechanism chosen and some data about it. It does > not report the other mechanisms attempted, or the possibly convoluted > path that led from the input to the output. While it's helpful, it > has proven inadequate. > > For instance, given a Windows user jordan@example.com and a mapping rule > $ idmap list > add winname:jordan@example.com unixuser:badunix > > idmap show -cv says: > $ idmap show -cv jordan@example.com > winuser:jordan@example.com -> uid:60001 > Error: Mapping not found or inhibited > Failed Method: Name Rule > Rule: add winname:jordan@example.com unixuser:badunix > > That's actually not too bad; although it doesn't point straight at the > problem, it at least reports the name that couldn't be found. > > -V, on the other hand, documents each step in the mapping process. > idmap show -cV says the following. (Note that since it's an error > case you get the "-v" output for free.) > > $ idmap show -cV jordan@example.com > winuser:jordan@example.com -> uid:60001 > Error: Mapping not found or inhibited > Failed Method: Name Rule > Rule: add winname:jordan@example.com unixuser:badunix > winname jordan@example.com -> unknown - Start mapping > winname jordan@example.com -> unixname - Not a well-known account > winname jordan@example.com -> unixname - Not a local SID > winname jordan@example.com -> unixname - Not found in mapping > cache > winname jordan@example.com -> unixname - Not found in name cache > winuser jordan@example.com > S-1-5-21-3591674789-480817656-4239000414-1106 -> unixuser - AD lookup > winuser jordan@example.com > S-1-5-21-3591674789-480817656-4239000414-1106 -> unixuser - Matching > rule: jordan@example.com -> badunix > winuser jordan@example.com > S-1-5-21-3591674789-480817656-4239000414-1106 -> unixuser - badunix > not found, error > winuser jordan@example.com > S-1-5-21-3591674789-480817656-4239000414-1106 -> unixuser - Rule-based > mapping error=-9981 > winuser jordan@example.com > S-1-5-21-3591674789-480817656-4239000414-1106 -> unixuser 60001 Error > -9981 - Done > > > Here's a more subtle case. Given this rule: > > $ idmap list > add winname:*@example.com unixuser:* > > $ idmap show -cv jordan@example.com > winuser:jordan@example.com -> uid:2147516418 > Source: New > Method: Ephemeral > > Note that -v doesn't tell us why we ended up with an Ephemeral mapping > instead of using the rule. > > $ idmap show -cV jordan@example.com > winuser:jordan@example.com -> uid:2147516419 > [[ BTW: it's a different ephemeral ID because I wiped the > cache between the two examples ]] > Trace: > winname jordan@example.com -> unknown - Start mapping > winname jordan@example.com -> unixname - Not a well-known > account > winname jordan@example.com -> unixname - Not a local SID > winname jordan@example.com -> unixname - Not found in > mapping cache > winname jordan@example.com -> unixname - Not found in name > cache > winuser jordan@example.com > S-1-5-21-3591674789-480817656-4239000414-1106 -> unixuser - AD lookup > winuser jordan@example.com > S-1-5-21-3591674789-480817656-4239000414-1106 -> unixuser - Matching > rule: *@example.com -> * > winuser jordan@example.com > S-1-5-21-3591674789-480817656-4239000414-1106 -> unixuser - jordan not > found, continuing > winuser jordan@example.com > S-1-5-21-3591674789-480817656-4239000414-1106 -> unixuser - No > matching rule > winuser jordan@example.com > S-1-5-21-3591674789-480817656-4239000414-1106 -> unixuser 2147516419 - > Ephemeral mapping > winuser jordan@example.com > S-1-5-21-3591674789-480817656-4239000414-1106 -> unixuser 2147516419 - > Done > > While my hypothetical Windows username is "jordan", my UNIX username > is "jb25718", and so the wild-card rule couldn't be used. (A > variation on this is a real customer case; their name service wasn't > set up right and UNIX users weren't getting looked up properly.) > > Or suppose I've transcribed my SID incorrectly (and unresolvable SID > mapping is enabled, as it is by default these days): > > $ idmap list > add winname:jordan@a.jb25718.west.sun.com unixuser:jb25718 > > $ idmap show -cv sid:S-1-5-21-3591674780-480817656-4239000414-1106 > unixuser > usid:S-1-5-21-3591674780-480817656-4239000414-1106 -> uid:2147516421 > Source: New > Method: Ephemeral > > $ idmap show -cV sid:S-1-5-21-3591674780-480817656-4239000414-1106 > unixuser > usid:S-1-5-21-3591674780-480817656-4239000414-1106 -> uid:2147516422 > Trace: > winname S-1-5-21-3591674780-480817656-4239000414-1106 -> > unknown - Start mapping > winname S-1-5-21-3591674780-480817656-4239000414-1106 -> > unixuser - Not a well-known account > winname S-1-5-21-3591674780-480817656-4239000414-1106 -> > unixuser - Not a local SID > winname S-1-5-21-3591674780-480817656-4239000414-1106 -> > unixuser - Not found in mapping cache > winname S-1-5-21-3591674780-480817656-4239000414-1106 -> > unixuser - Not found in name cache > winname S-1-5-21-3591674780-480817656-4239000414-1106 -> > unixuser Error -9976 - AD lookup > winuser S-1-5-21-3591674780-480817656-4239000414-1106 -> > unixuser Error -9976 - Must map unresolvable SID to user > winuser S-1-5-21-3591674780-480817656-4239000414-1106 -> > unixuser 2147516422 Error -9976 - Ephemeral mapping > winuser S-1-5-21-3591674780-480817656-4239000414-1106 -> > unixuser 2147516422 - Done > > The idea is that -V doesn't just document the result; it documents > each piece of information, where it came from, and what decisions were > made based on that data. > -- * Michael Kearney * Principal Software Engineer *Oracle Corp.* MS UBRM05-390, 500 Eldorado Blvd Broomfield, CO 80021 US Phone 303-272-2402 Fax 303-272-6554 Email Michael.Kearney@Oracle.COM --Boundary_(ID_jgsjB9PnDILAWs5isJpjLA) Content-type: text/html; charset=UTF-8 Content-transfer-encoding: 8BIT +1

Thank you for the explanation.

       Regards,
          Michael

On 4/16/2010 10:36 AM, Jordan Brown wrote:
[ You'll probably want a wide window to view the output lines here.  I could probably have the program break them up a bit, but some of the data fields are pretty long and might wrap anyway, and it's not clear that multiline entries would be more readable. ]

Michael Kearney wrote:
I note that the show option already has a lowercase -v option.
The -v option shows how the mapping was generated and also
whether the mapping was just generated or was retrieved from the cache.

How are -v and -V different?

-v reports the _one_ mechanism chosen and some data about it.  It does not report the other mechanisms attempted, or the possibly convoluted path that led from the input to the output.  While it's helpful, it has proven inadequate.

For instance, given a Windows user jordan@example.com and a mapping rule
    $ idmap list
    add     winname:jordan@example.com   unixuser:badunix

idmap show -cv says:
    $ idmap show -cv jordan@example.com
    winuser:jordan@example.com -> uid:60001
    Error:  Mapping not found or inhibited
    Failed Method:  Name Rule
    Rule:   add     winname:jordan@example.com   unixuser:badunix

That's actually not too bad; although it doesn't point straight at the problem, it at least reports the name that couldn't be found.

-V, on the other hand, documents each step in the mapping process.  idmap show -cV says the following.  (Note that since it's an error case you get the "-v" output for free.)

    $ idmap show -cV jordan@example.com
    winuser:jordan@example.com -> uid:60001
    Error:  Mapping not found or inhibited
    Failed Method:  Name Rule
    Rule:   add     winname:jordan@example.com   unixuser:badunix
        winname jordan@example.com -> unknown - Start mapping
        winname jordan@example.com -> unixname - Not a well-known account
        winname jordan@example.com -> unixname - Not a local SID
        winname jordan@example.com -> unixname - Not found in mapping cache
        winname jordan@example.com -> unixname - Not found in name cache
        winuser jordan@example.com S-1-5-21-3591674789-480817656-4239000414-1106 -> unixuser - AD lookup
        winuser jordan@example.com S-1-5-21-3591674789-480817656-4239000414-1106 -> unixuser - Matching rule: jordan@example.com -> badunix
        winuser jordan@example.com S-1-5-21-3591674789-480817656-4239000414-1106 -> unixuser - badunix not found, error
        winuser jordan@example.com S-1-5-21-3591674789-480817656-4239000414-1106 -> unixuser - Rule-based mapping error=-9981
        winuser jordan@example.com S-1-5-21-3591674789-480817656-4239000414-1106 -> unixuser 60001 Error -9981 - Done


Here's a more subtle case.  Given this rule:

    $ idmap list
    add     winname:*@example.com        unixuser:*

    $ idmap show -cv jordan@example.com
    winuser:jordan@example.com -> uid:2147516418
    Source: New
    Method: Ephemeral

Note that -v doesn't tell us why we ended up with an Ephemeral mapping instead of using the rule.

    $ idmap show -cV jordan@example.com
    winuser:jordan@example.com -> uid:2147516419
          [[ BTW:  it's a different ephemeral ID because I wiped the cache between the two examples ]]
    Trace:
            winname jordan@example.com -> unknown - Start mapping
            winname jordan@example.com -> unixname - Not a well-known account
            winname jordan@example.com -> unixname - Not a local SID
            winname jordan@example.com -> unixname - Not found in mapping cache
            winname jordan@example.com -> unixname - Not found in name cache
            winuser jordan@example.com S-1-5-21-3591674789-480817656-4239000414-1106 -> unixuser - AD lookup
            winuser jordan@example.com S-1-5-21-3591674789-480817656-4239000414-1106 -> unixuser - Matching rule:     *@example.com -> *
            winuser jordan@example.com S-1-5-21-3591674789-480817656-4239000414-1106 -> unixuser - jordan not found, continuing
            winuser jordan@example.com S-1-5-21-3591674789-480817656-4239000414-1106 -> unixuser - No matching rule
            winuser jordan@example.com S-1-5-21-3591674789-480817656-4239000414-1106 -> unixuser 2147516419 - Ephemeral     mapping
            winuser jordan@example.com S-1-5-21-3591674789-480817656-4239000414-1106 -> unixuser 2147516419 - Done

While my hypothetical Windows username is "jordan", my UNIX username is "jb25718", and so the wild-card rule couldn't be used.    (A variation on this is a real customer case; their name service wasn't set up right and UNIX users weren't getting looked up properly.)

Or suppose I've transcribed my SID incorrectly (and unresolvable SID mapping is enabled, as it is by default these days):

    $ idmap list
    add     winname:jordan@a.jb25718.west.sun.com   unixuser:jb25718

    $ idmap show -cv sid:S-1-5-21-3591674780-480817656-4239000414-1106 unixuser
    usid:S-1-5-21-3591674780-480817656-4239000414-1106 -> uid:2147516421
    Source: New
    Method: Ephemeral

    $ idmap show -cV sid:S-1-5-21-3591674780-480817656-4239000414-1106 unixuser
    usid:S-1-5-21-3591674780-480817656-4239000414-1106 -> uid:2147516422
    Trace:
            winname S-1-5-21-3591674780-480817656-4239000414-1106 -> unknown - Start mapping
            winname S-1-5-21-3591674780-480817656-4239000414-1106 -> unixuser - Not a well-known account
            winname S-1-5-21-3591674780-480817656-4239000414-1106 -> unixuser - Not a local SID
            winname S-1-5-21-3591674780-480817656-4239000414-1106 -> unixuser - Not found in mapping cache
            winname S-1-5-21-3591674780-480817656-4239000414-1106 -> unixuser - Not found in name cache
            winname S-1-5-21-3591674780-480817656-4239000414-1106 -> unixuser Error -9976 - AD lookup
            winuser S-1-5-21-3591674780-480817656-4239000414-1106 -> unixuser Error -9976 - Must map unresolvable SID to user
            winuser S-1-5-21-3591674780-480817656-4239000414-1106 -> unixuser 2147516422 Error -9976 - Ephemeral mapping
            winuser S-1-5-21-3591674780-480817656-4239000414-1106 -> unixuser 2147516422 - Done

The idea is that -V doesn't just document the result; it documents each piece of information, where it came from, and what decisions were made based on that data.


--
Michael Kearney
Principal Software Engineer

Oracle Corp.
MS UBRM05-390, 500 Eldorado Blvd
Broomfield, CO 80021 US
Phone 303-272-2402
Fax 303-272-6554
Email Michael.Kearney@Oracle.COM
--Boundary_(ID_jgsjB9PnDILAWs5isJpjLA)-- --Boundary_(ID_fAeaccvvuHSYO3drpwfeZA) Content-type: text/x-vcard; charset=utf-8; name=michael_kearney.vcf Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=michael_kearney.vcf begin:vcard fn:Michael Kearney n:Kearney;Michael org:VTCS Enterprise Engineering;Tikka adr:;;500 Eldorado Blvd;Broomfield;CO;80021;USA email;internet:michael.kearney@oracle.com title:Principal Software Engineer tel;work:303-272-2402 url:http://www.oracle.com version:2.1 end:vcard --Boundary_(ID_fAeaccvvuHSYO3drpwfeZA)-- From Jordan.Brown@oracle.com Sat Apr 17 21:13:44 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o3I4DihW008184 for ; Sat, 17 Apr 2010 21:13:44 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o3I4Dh0e031233 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Sat, 17 Apr 2010 22:13:43 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L1200H0312VIA00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sat, 17 Apr 2010 21:13:43 -0700 (PDT) Received: from sca-ea-mail-4.sun.com ([192.18.43.22]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L1200GGR12VW700@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sat, 17 Apr 2010 21:13:43 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o3I4Dh49014168 for ; Sun, 18 Apr 2010 04:13:43 +0000 (GMT) Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o3I32qhG027386 for ; Sun, 18 Apr 2010 04:13:42 +0000 (GMT) Received: from abhmt012.oracle.com by acsmt354.oracle.com with ESMTP id 184967131271562192; Sat, 17 Apr 2010 20:43:12 -0700 Received: from [129.145.155.152] (/129.145.155.152) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 17 Apr 2010 20:43:12 -0700 Date: Sat, 17 Apr 2010 20:43:10 -0700 From: Jordan Brown Subject: idmap show -V mapping trace mechanism [PSARC/2010/125 FastTrack timeout 04/16/2010] To: PSARC-ext@sun.com Message-id: <4BCA7FCE.8080208@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090202.4BCA86F6.0179:SCFMA4539814,ss=1,fgs=0 User-Agent: Thunderbird 2.0.0.14 (X11/20080505) Status: RO Content-Length: 145 The timer having expired, a +1 having been received, and all questions having been answered, I'm declaring this case closed approved. Thanks.