Lab 15a: Exploring Secure Shell Kerberos SSO with Centrify for UNIX/Linux

Background

Review the SSO posting: http://centrifying.blogspot.com/2014/01/basics-centrify-for-unixlinux-sso.html 

In this lab:

1. We will install Centrify OpenSSH in CEN1
2. We will explore the location of binaries, config files and services for Centrify-OpenSSH
3. We will install Centrify-enhanced PuTTY
4. We will test Kerberos SSO

Basics: Privilege Management Implemeting (Do) on UNIX/Linux using Centrify and Active Directory

Background

This is the implementation portion of the 4-part series around Privilege Management with Centrify for UNIX/Linux.  Read the previous post to catch up.  The basic knowledge for this post, although focused on UNIX, it's applicable with the exception of rights, applies to Windows too.  The activities required to implement roles with Centrify requires:

1. Create Computer Roles if needed
2. Create and Configure Roles
• Build the PAM access rights if needed
• Build the Commands if needed
3. Assign the role

Creating Computer Roles

Centrify computer roles are groupings of systems that perform a particular role.  I like to call them computer groups.  Systems can be grouped any way it makes sense to you.  The real power of computer roes is that they are based on AD Security groups, this means that you can have computers (just like users) that have multiple roles.   Examples:

• Fragmented (vertical) model:  Web, Database, Utility, Network Services, etc.
• Mixed mode (horizontal/cross funtional)l:  Application X - Dev; Application X - Prod  (Application X has Database, Web and Application servers).

To create a computer role:

1. Create an AD Security Group  (this is the Computer Role container)
2. In Access Manager, Open the Zone, and expand Authorization > Computer Roles
3. Right click Computer Roles and select Create New Computer Role
   
4. Set the name, and browse for the AD group created in step 1.

What happens when you create a Computer Role?

A computer role adds a new scope to assign RBAC and to categorize systems.  The operations associated with Computer Roles are role assignment and member add/moves/changes.

The add/moves/changes for roles are performed within the AD group that grants the role, this makes the Role Assignment a first time/adjustment activity.

Creating Roles

Centrify roles are the building blocks for Role-Based Access Controls.  Roles are defined, then assigned to AD security principals.  In UNIX roles are composed of PAM Access and Commands.

• PAM Access:  Defines the PAM-aware protocols that are allowed in the the role.  Examples:  Secure Shell (ssh), xdm, VNC, and of course, not recommended:  pure telnet & FTP.  The built-in login-all  PAM right allows access on all protocols including the console.
  Note for AIX:  Some AIX platforms are configured for LAM can't provide granular access.
• Commands:  are the privileged (or non-privileged) commands defined for the role.  They can be defined explicitly, or with regular expressions, tied to the Centrify restricted shell, scoped for a particular user, and defined with additional authentication requirements.

To create roles:

You need to know how the role will access the system (e.g. via SSH), what privileged commands it needs (e.g. service control for httpd), any time restrictions and if you have Centrify Enterprise, you

1. In Access Manager open the Zone > Authorization > Role Definitions
2. First, always review your roles to see if a role exists that can be reused.
3. Examine PAM The UNIX Rights definitions node for PAM and Commands and make sure the building blocks exist.
4. Right Click Role definitions and Select Add Role
5. Name the role, use the description field and add any time/day restrictions if needed.
   
6. Go to the System Rights tab.  Define the logon experience. 
• Password login and non-password login (SSO) are allowed:  if  you plan to use both SSO and passwords  (check it)
• Non-Password SSO login allowed:  You would uncheck the one above and only check this if you're in a Smart Card scenario.  (check it)
• Account disabled in AD can be used by sudo, cron, etc:  Only required if you're defining a role for a service account managed from AD.  (leave unchecked)
• Login with a non-Restricted Shell:  This is going to be not selected if using the Centrify Restricted shell (white-list mode).  (check it)
  
  Note the Windows rights, not covered in this posting.
7. If using Enterprise Edition, go to the Audit Tab, and select the appropriate option:
   
   Especially when Auditing roles for Windows, the integration of RBAC and auditing can result in auditing risky actions and less storage usage in the Audit database.
8. Press OK.
   Very important: At this point, the role is defined, but it has no rights assigned to it, this has to be the most common mistake in the area of RBAC along with assigning a role without granting an identity.  
9. Right-click the newly-created role and select Add Rights
   
   Check all the rights (PAM) and commands for the role and press OK.

Now the role is ready to use (be assigned).

Assigning Roles

As described, Role assignment is the granting of a UNIX (or Windows) role to an AD Security Principal in the correct scope.  Roles can be assigned at:

• Zone Level:  This role will apply to all systems in the zone.  (Limited Use)
• Child Zone:  This role will apply to the child zone (Depends on your design)
• Computer Role:  This role will apply just to the set of systems in the role (Optimal usage)
• Computer:  This is a local override or exception  (If you find yourself doing this a lot, you have a governance problem)

Time-bounding Role Assignments

Permanent vs. Temporary Role assignments:  Time-bounding of role assignments is a powerful feature of Centrify, this allows for scenarios like this:

• Change-control windows:  You can have your population be regular users all the time, and only get a role with privileges when a change control has been granted.  The access/rights expire automatically at the time specified.
• Contractor scenarios:  A set of external users may need access to systems in a specified period of time.

With the AD Group, scope and time, all the information is ready for do do an assignment.

1. In Access Manager, go to Zone > Authorization
2. At this point, it's time to pick the scope:
• To assign at the zone/child zone level, select the Role Assignments node right under authorization.
• To assign at the Computer Role level, expand Computer Roles, find the correct system group, and expand to expose Role assignments
• Exception:  At the system level, go to the Computers node, find the computer, expand it and find Role Assignments.
3. Right click Role Assignments and select Assign Role, then pick the role you are going to assign.
   
4. In the Assign Role box, time-bound based on your information (scope or permanent), then use the Add AD Account button and find the Group (or user -not recommended- promotes exceptions) that you will grant the role to and press OK.
   

Process Reuse: The biggest benefit of assigning the role to a group is that this makes the integration with other tools and process reuse much easier.

In the next post we will talk about the Check (Verify the implementation) portion of Privilege Management.

Basics: Privilege Management Planning on UNIX/Linux using Centrify and Active Directory

Background

Privilege Management (or Privilege Access Management):  is the capability to control and limit users activities in accordance with the least privilege principle, some key goals:

• Limit access to systems based on business need-to-know
• Limit privileges or actions to those required to perform the job function
• Provide timely information for the purposes of attestation or auditing
• Enforce separation of duties.

In the context of UNIX and Linux systems, Centrify provides capabilities to establish a Privilege Management model that satisfies all these goals (since version 2013, these benefits extend to Windows systems too).

To perform a Plan-Do-Check-Adjust exercise on Privilege management, we will break down the activities in Access, Privileges, Governance and Reporting.  To keep the posts a short read, we'll focus on planning.

Planning Privilege Management with Centrify for UNIX/Linux

Governance

Governance is related to separation of duties and ideally, the people who define the access, rights and privileges (Security Analysts, compliance, etc.) are different than the people who access the systems (System Admins, DBAs, etc);  however, in the real world the expertise and organizational history required to establish a governance model is in the hands of the most senior administrators.  

Delegation of Centrify objects is performed in two places:

• In Active Directory (this is another topic)
• At the zone level, Centrify breaks the actions to be performed as follows:

Rights	Category	Description
Change zone properties	Operational	Changing zone properties may imply changing the UID/GID defaults, renaming the zone or how the zone is provisioned.  These actions should be change-controlled.
Add users	Operational	Adding users is basically UNIX-enabled AD users.  This is delegated to the ZPA service account in an automatically provisioning scenario.  In a manual zone, this is just day-to day activities.
Add groups	Operational	Same as above, but with groups; however, this is a one-time setting, the real operations are Add/Removes from the mapped AD group.
Join computers to the zone	Operational	This is the equivalent to joining computers to the domain, the Windows process can be reused here.  UNIX operations are typically granted this role.
Remove zones	Operational	Deleting zones (in production) should be a change-controlled activity.
Remove users	Operational	See “Add users”
Remove groups	Operational	See “Add groups”
Remove computers from the zone	Operational	See “Join computers to the zone”
Modify user profiles	Operational	See “Add users”
Modify group profiles	Operational	See “Add groups”
Allow computers to respond to NIS client requests	Operational	With Centrify, NIS maps can be reused securely in a clientless scenario, Operations may need to configure computers to act as NIS proxies for appliances, legacy systems, etc.
Import users and groups to the zone	Operational	See “Add groups”
Manage roles and rights	Governance	Roles and rights are the building blocks of RBAC.  See below.  This activity should be reserved for Security or Compliance, although in an initial implementation may be granted to UNIX administrators.
Manage role assignments	Governance	Role assignments entitle AD user or group principals to access or privileges based on a role.  The guidance is the same as “Manage roles and rights.”
Modify computer roles	Governance	Computer Roles are the groupings of systems.  They define the types of systems and the scope of access. The guidance is the same as “Manage roles and rights.”
Add or remove NIS map entries	Operational	With Centrify, NIS maps can be reused securely in a client scenario, Operations may need to add/remove/change those maps.
Modify NIS map entries	Operational	See “Add/Remove NIS map entries”
Remove NIS maps	Operational	See “Add/Remove NIS map entries”

During the implementation phase, the trusted administrators that are implementing Centrify may have full control, but as the implementation matures, as part of the adjust phase, the governance rights can be split from operations.  The key questions are:

• Who are the individuals that have operational responsibility for your UNIX/Linux systems?
• Who are the individuals that have governance responsibility for your UNIX/Linux systems?
• Is there a geographical o divisional breakdown that we should be aware of?
  The answer to this final question is very important.  It may trigger the need to have parallel or child zones.  Try to do as much as you can to keep things as flat as possible.

Privileges

Planning for privileges is one of the hardest activities;  and this is because the people using the system may not be used to thinking about Roles-Based Access Controls.  A good starting point may be a sudoers file (Centrify can import them); but even that may carry legacy information;  the worst case scenario is the implementation of a centralized mess.  Here are some base questions for a table-top exercise:

Questions	Typical answers	Comments
1.      What are the user populations that access UNIX/Linux systems?	DBAs, Developers, System Administrators, etc.	The goal of this question should be to identify user populations.  Moderating the scope of this answer is critical. Also, try to find out if users are within an AD domain, across domains, etc.  This has an effect on the type of Security groups used for role assignment.
2.      What are the groups of systems they access today?	Oracle servers, Apache servers, Dev Servers, Filers, etc.	The goal of this question is to identify how systems should be grouped.  This question is the key to establish the governance model because it will produce the Computer Roles.  An advantage of Centrify is that a system can have multiple roles.  It can be a Database System and a Web System at the same time.
3.      What are the groups of systems they should have access to?	The answer varies	It’s possible that this may be the hardest question to answer; this is because other than Netgroups, organizations may not have a mature way to group systems and grant access.
4.      How do these users access the systems today?	SSH, console, VNC, FTP, NFS, Samba, etc	This is key, because Centrify can control how PAM access is granted.
5.      How do these users should access these systems?	This varies too	With Virtualization, console access is rare; also, unless there are HPUX, Solaris or AIX systems, console access is limited to a trusted set of administrators; there will be a bias towards SSH, but even that can be controlled granularity with Centrify.
6.      How do people use privileges today?	The answer to this question may vary.	The best way to explain this is with an example.  How do DBAs use the oracle account? Answer: “they access with their account, and sudo as oracle or su to oracle” Upon verification, turns out those DBAs were logging in directly with the Oracle account.
7.      What are the privileges that they have today?	Everyone is can be root, sudo access, etc.	The answer to this question depends on the maturity level of the organization.
8.      What are the privileges that they should have?	The answer varies	Just like the answer to question 3, since the possibilities are unknown, it may be hard to get.

Again, the hardest part of this planning exercise is to get people that know enough about what's possible with Centrify (see implementation below), and that privilege management has its own roadmap. 

Access

Access involves planning the types of systems available in the enterprise.  Grouping systems based on type,  or environment allows the scoping of roles to be tied to groups of servers, effectively enforcing both access and privileges.  For example, a group of systems may be defined for Application A, that has web, application and database servers; it's possible to group these systems together and have a different access/privilege model for DEV, QA and Prod.

The Output of the Planning Session

In Business Problem # 1, the access model was well defined;  and in Business Problem #2, the privigeles are going to be expanded:

User Populations	Access / Protocols	Privileges
System Administrators	All Systems via any protocol	Run any command as root
DBAs	Database Systems via SSH	Elevate to db2inst Run db2 commands as db2inst DB2 instance service control
Web Admins	Web Systems via SSH	HTTP daemon service control (as root) Edit http daemon configuration file (as root)
Developers	Database and Web Systems via SSH	Run application X, service control
All UNIX-enabled users	Listed on Filers	No access, no privileges.

Stay tuned, in the next post we'll talk about Implementation and Verification.

Lab 15a: Exploring SSH GSSAPI SSO with Centrify for UNIX/Linux

Background

Review the SSO posting: http://centrifying.blogspot.com/2014/01/basics-centrify-for-unixlinux-sso.html 

In this lab:

1. We explore Kerberos tickets in Windows with klist
2. We review the Service Principal Names (SPNs) for CEN1
3. We review the SPNs with adinfo -C
4. We review the Generic Security Services API (GSSAPI) settings for OpenSSH (Server)
5. We review the GSSAPI settings for PuTTY (Client)
6. We establish an SSO session to CEN1.

Basics: Centrify Support for Single Sign-on (SSO) on UNIX/Linux

Background

It seems that SSO or Single Sign-on means different things to different people:

• To some people, it means having a single-set of sign-on credentials across multiple systems regardless of the authentication experience.  I would call this unified credentials or unified identity.
• To others, SSO means silent sign-on, or authenticate once to a system, and then you don't have to authenticate again regardless of the systems that are accessed.
• Finally, some other people hear SSO and immediately they think about Web application SSO.

Garner has the following definition:

"Single sign-on (SSO) provides the capability to authenticate once, and be subsequently and automatically authenticated when accessing various target systems. It eliminates the need to separately authenticate and sign on to individual applications and systems, essentially serving as a user surrogate between client workstations and target systems. Target applications and systems still maintain their own credential stores and present sign-on prompts to client devices. Behind the scenes, SSO responds to those prompts and maps the credentials to a single login/password pair. SSO is commonly deployed in enterprise, Web and federated models."

This means that the best way to talk about SSO is to qualify it.  I like to look at it from the perspective of how its implemented.

• Direct Access:  In this case, there's a central directory, like Active Directory, that provides secure authentication services (like Kerberos) and the systems (e.g. like UNIX, Linux) or Services (like Apache, Tomcat, Java, etc) can provide authentication services directly, with minimal or no middleware required.  For example:  An Apache server can leverage shared objects and libraries to extend OS authentication services (like Kerberos) out to clients.
  I prefer this approach because requires next to zero infrastructure, processes, technology, etc. and the barrier of implementation relatively simple.
• Through Middleware:  In this case, we have servers, processes, people, technology that implement transformations, synchronizations, claims, transactions, capabilities, etc that provide SSO services.
  This method is very complex.

SSO Services Provided by Centrify for UNIX and Linux

Centrify provides SSO services to access to UNIX/Linux and Services (Web, Java, SAP, etc with plugins) with the user's Active Directory account leveraging Kerberos or the Generic Security Services Application Programming Interface (GSSAPI).  Here's an example:

Using Secure Shell (SSH)

1. A UNIX-enabled Active Directory user logs into their Windows computer
At this point, the user gets a ticket-granting ticket as part of the Kerberos process in Windows.  This can verified with the klist command:

#0>     Client: jessie.matthews @ CORP.CONTOSO.COM

        Server: krbtgt/CORP.CONTOSO.COM @ CORP.CONTOSO.COM

        KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96

        Ticket Flags 0x60a00000 -> forwardable forwarded <...>

        Start Time: 1/16/2014 23:03:42 (local)

        End Time:   1/17/2014 9:03:41 (local)

        Renew Time: 1/23/2014 23:03:41 (local)

        Session Key Type: AES-256-CTS-HMAC-SHA1-96

2. The user uses an SSH client that supports GSSAPI or Kerberos to access a Centrified UNIX/Linux host that is running a version of the SSH server that supports GSSAPI or Kerberos.

At this point, the Kerberos negotiation process obtains/validates a ticket to access the host.

On the server, the version supports GSSAPI and the option is enabled.

OpenSSH_5.3p1, OpenSSL 1.0.1e-fips 11 Feb 2013

$ dzdo grep GSSAPIAuthentication /etc/ssh/sshd_config

GSSAPIAuthentication yes

When the Centrify software was installed, the Centrify shared libraries and PAM modules are put in place.  When the computer is joined to the domain, the Service Principal Names are registered for the system for example, here are the ones for CEN1:

Notice the host SPN

3. The user types in his username, and does not have to type the password and is securely authenticated.

After this successful login, here's the ticket for this host (notice the Server field that matches the SPN above)

#2>     Client: jessie.matthews @ CORP.CONTOSO.COM

        Server: host/cen1.corp.contoso.com @ CORP.CONTOSO.COM

        KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96

        Ticket Flags 0x40a00000 -> forwardable renewable <...>

        Start Time: 1/16/2014 23:05:10 (local)

        End Time:   1/17/2014 9:03:41 (local)

        Renew Time: 1/23/2014 23:03:41 (local)

        Session Key Type: AES-256-CTS-HMAC-SHA1-96

This is the same experience that someone that opens, let's say Microsoft Outlook, in their enterprise and is not prompted for a password.  Also, believe it or not, this happens in the back end when you access a file or printer share.  For example, everyone has to read the SYSVOL share of the domain controller.  Notice the CIFS ticket for DC1:

#3>     Client: jessie.matthews @ CORP.CONTOSO.COM

        Server: cifs/dc1.corp.contoso.com @ CORP.CONTOSO.COM

        KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96

        Ticket Flags 0x40a40000 -> forwardable renewable <...>

        Start Time: 1/16/2014 23:03:42 (local)

        End Time:   1/17/2014 9:03:41 (local)

        Renew Time: 1/23/2014 23:03:41 (local)

        Session Key Type: AES-256-CTS-HMAC-SHA1-96

From an SSH perspective, I am of the opinion that leveraging Kerberos or the GSSAPI is preferable than using user keys.  The former is tied to the user's identity and the latter introduces the risk of key management.

The topic of how Centrify offers services to Web and Java applications running on UNIX/Linux will be covered in future business problems, but for now, as discussed in the Kerberos post, there three common aspects:

1. An LDAP directory and a Kerberos environment (provided by AD)
2. Kerberized (or GSSAPI-compliant) services and clients
3. Centrify shared libraries.

Centrify also provides Kerberized client versions of Secure FTP, SMB, etc. as well as their own version of Kerberos tools.  For environments that have complex domain infrastructures like one-way trusts, Centrify provides their own enhanced version of OpenSSH, but it's not required to get these services.

When to use Centrify-enhanced OpenSSH

Centrify OpenSSH is a distribution of OpenSSH compiled with Centrify's Kerberos libraries, it's only required if you have a complex AD Domain infrastructure that scenarios like:

• One-way trusts
• Cross forest-trusts (External)

Centrify OpenSSH differs from stock SSH in that the name of the service, location of the binaries and config files are different.  As of version 2013.3, Centrify-OpenSSH is based on OpenSSH 6.2 P2.

Centrify PuTTY provides Kerberos authentication.

Security Corner: Establishing an Identity and Access Governance Model for UNIX/Linux with Centrify and Active Directory - Part 1

Background

An Identity and Access governance model establishes how end users will access your systems, this entails

• Establishing the rules of who should have access to which system
• Establishing what functions (or privileges) they're allowed to perform or use
• Establish the provisioning process (Add/Moves/Changes)

But first, a quick refresher:

Provisioning

As defined by the dictionary, provisioning  means to provide, the reverse is to withdraw or to deprovision.  

In Identity Management, provisioning may mean User provisioning into different systems from an authoritative source.  User provisioning as per Gartner is a whole IT capability (and a source of much confusion)

In the context Identity and Access Management with Centrify for UNIX, the authoritative source is Active Directory;  regardless of how the Active Directory user is provisioned (manually, with an Identity Management solution like Oracle, Courion or Sailpoint, or with other tools) UNIX identity provisioning in AD can be performed in different ways.  With Centrify, the preferred method is with a SCP that contains the user's identity (created manually via Access Manager, or automatically with the ZPA).  

Fortunately, Centrify makes the integration very easy.  It's all about placing users in a security group in AD.

As a refresher, for an AD user to have access to UNIX system in a Centrify Zone, they need two things:

• A user Identity
• A role that allows the right to log in

Therefore, both identities and roles can be granted (provisioned) and removed (deprovisioned).  Centrify implements an RBAC model for UNIX that grants Access and Privileges.

The group nesting feature of AD can be leveraged
to provide Identity and Access with automation.

Access

In a properly managed enterprise, not everyone has access to all systems, and with Centrify you can implement virtually any governance model.  The design ideally is as flat as possible, with a single hierarchical zone and computer roles as the way to establish a governance model.  For example, in our lab we have a simple Access Model:

• Web Servers can be accessed by super users and web administrators
• Database Servers can be accessed by super users and DBAs
• Filers can be accessed by super users, and all UNIX users are listed in the system.

This model works great for our example, but we know that the real world is different.  The guideline is to try to enforce the least access principle.

In Centrify,  access is granted by direct assignment or by making a user a member of an AD group that has been granted the assignment (role granting group), the rest implies to manage the server memberships.

For example:  when a new web server is provisioned, it's dropped into the Web Servers group, and by way of the role assignment, all users that have access (and privileges) will get access automatically.

Privileges

With Centrify, in UNIX, the rights are:

• PAM Access: meaning, "how the system is accessed" or "what protocol"   this allows to grant access via the console and SSH for super users, but only SSH for the rest of the world.  We can go deeper into SSH rights, like allowing a secure file copy, but we aren't going to go that deep.
• Commands:  meaning "what can the user do?" "in the context of what account?" etc.  For example, a super user may leverage Centrify-enhanced sudo to run any command as root, but a DBA may only have one privileged command, like "su - oracle"

Note that Centrify can also perform privilege management for Windows, but that's a whole other topic.  In here, the idea is to start broad (define super users and regular users) and slowly adjust to provide people with the roles that give them just what they need, again, in accordance with the least access principle.

With Centrify roles, there are other settings that can be adjusted like:

• At what time is the role available?  (e.g.  backup operator that runs the tar command as root from 10pm to 4am)
• What is the shell experience for privileged commands (a whitelist of commands or a free-range shell)
• Is the role permanent or just temporary (like in a change control window)

In Centrify,  privileges are granted by direct assignment or by making a user a member of an AD group that has been granted the assignment.

Putting it all together

1. Centrify does not provision AD users, this happens upstream (manually, Idm, etc)
2. To access Centrified servers in AD in a zone a user needs an identity and a role that grants access and privileges.
3. Identities can be granted manually or automatically (by placing the user into an AD provisioning group)
4. Access and privileges can be granted manually or automatically (directly or by placing a user into an AD role-granting group)
5. The reverse of 3 and 4 is possible.
6. Automation and integration is always possible and very simple due to the link to AD groups.

Utilities: addns and adsmb

addns

This utility is allows the register and update of the system DNS resource record either automatically or manually.  It is very handy especially for UNIX administrators that may not have access to the DNS management snap-in.  addns uses secure DNS dynamic updates.

For example, to update my computer (ubu1), in the corp.contoso.com using jessie's account:

$ ifconfig eth0
eth0      Link encap:Ethernet  HWaddr 00:0c:29:1f:2c:0a
          inet addr:10.0.0.154  

$ addns -U -u jmatthews  -d corp.contoso.com -n ubu1 -i 10.0.0.154
jmatthews@CORP.CONTOSO.COM's password:
Updating host records for ubu1.corp.contoso.com on 10.0.0.1.
Updated host records ubu1.corp.contoso.com.
Updating reverse lookup records for ubu1.corp.contoso.com on 10.0.0.1.
Updated reverse lookup record  154.0.0.10.in-addr.arpa.

In DNS Manager, I can see my updated record

addns Usage

    addns -U [-u <user> -p <pwd>] [-d <dom>] [-s <svr>] [-n <host>] [(-i <ip>)+]

Or:

    addns -D [-u <user> -p <pwd>] [-d <dom>] [-s <svr>] [-n <host>]

Or:

    addns -A [-u <user> -p <pwd>] [-d <dom>] [-s <svr>] [-n <host>] [(-i <ip>)+]

Or:

    addns -L [-d <dom>] [-s <svr>] [-n <host>] [(-i <ip>)+]

With:

  -U, --update        create or update host's DNS records

  -D, --delete        delete host's DNS records

  -A, --add           just add host's DNS records

  -L, --list          lists DNS record details

  -N, --nocreds       no credential is to be supplied or prompted for (only works when the DNS server is configured for non-secured updates)

  -m, --machine       Use machine credentials (must be root)

  -u, --user          AD user name

  -p, --password      pwd password string, prompts if absent

  -s, --server        svr DNS server to contact. Legal formats include: host<@REALM>, host.domain.com<@REALM>

  -d, --domain        dmn DNS domain name

  -n, --name          hst Host Name

  -i, --ipaddr        ipa IP address

  -f, --force         force update DNS records even if they have not changed

  -r, --refresh       updates unchanged records to refresh TTL

  -t, --ttl           val specify a time to live value in seconds

  -v, --version       print version information and exit

  -V, --verbose       print debug information for each operation

  -h, --help          print this help information and exit

Examples:

    addns -U

    addns -D

    addns -U -d acme.com -s dnssvr@ACME_REALM.COM -n myhost -i 192.168.1.155

    addns -L

adsmb

This is a very cool tool that allows to access windows shares via the command line.  It allows to copy, read and even print!! files from the command line interface to windows shares.  adsmb can use the current machine credentials and even a kerberos keytab to authenticate (great for scripts!)

Folder listing example:  To list the files in the files folder in APP1  (\\APP1\files)

$ adsmb dir -h app1.corp.contoso.com -s files

  10 Sat Dec 14 14:39:38 2013, Wed Dec 18 06:27:39 2013,  Wed Dec 18 06:27:39 2013,  Wed Dec 18 06:27:39 2013,               0 .

  10 Sat Dec 14 14:39:38 2013, Wed Dec 18 06:27:39 2013,  Wed Dec 18 06:27:39 2013,  Wed Dec 18 06:27:39 2013,               0 ..

  10 Sun Dec 15 19:30:14 2013, Sun Dec 15 19:32:08 2013,  Sun Dec 15 19:32:08 2013,  Sun Dec 15 19:32:08 2013,               0 Centrify-Suite-2013.3-mgmt-ent-win64

  20 Wed Dec 18 06:27:39 2013, Wed Dec 18 06:26:06 2013,  Tue Jan 14 18:06:55 2014,  Wed Dec 18 06:27:39 2013,        39118052 centrify-suite-2013.3-rhel3-x86_64.tgz

  20 Wed Dec 18 06:27:39 2013, Wed Dec 18 06:26:22 2013,  Tue Jan 14 18:06:55 2014,  Wed Dec 18 06:27:39 2013,        30561472 centrify-suite-2013.3-sol9-x86.tgz

  20 Wed Dec 18 06:27:39 2013, Wed Dec 18 06:26:38 2013,  Tue Jan 14 18:06:55 2014,  Wed Dec 18 06:27:39 2013,        31055871 centrify-suite-2013.3-suse9-x86_64.tgz

  20 Sat Dec 14 14:40:51 2013, Sat Dec 14 14:40:51 2013,  Tue Jan 14 18:06:55 2014,  Sat Dec 14 14:40:51 2013,              21 example.txt

File get example: to copy example.txt to the Files shared folder in APP1

$ adsmb get -h app1.corp.contoso.com -s files -r example.txt -l example.txt

$ ls -l

total 4

-rw------- 1 jmatthews jmatthews 21 Dec 14 14:40 example.txt

-rw-rw-r-- 1 jmatthews jmatthews  0 Jan 14 17:59 myfile.txt

$ cat example.txt

This is a shared file

jmatthews@ubu1:~$

adsmb Usage

Usage: adsmb <action> [-c credentials] [-d domain] [-h host] -s share [-r file] [-l file ] [-n pattern] [-CmTV]

        action = get, getnew, getmod, put, putnew, print, dir, mkdir, rename, rmdir, delete

        -c credentials = credentials to use

        -h host   = host to connect to. If not given it is the 'best' domain controller

        -d domain = domain to connect to. If not given it is using current joined domain or the domain part from the host

        -s share  = share name

        -r file   = the remote file or remote directory to dir

        -n pattern= pattern to list when listing directory, default is *

        -l file   = the local file

        -C = convert CRLF to LF

        -m = use machine credentials. Requires access to krb5.keytab, typically root

        -T = Machine-readable timestamps

        -V = print debug message

Examples:

        adsmb get -h myserver -s test -r files\\my.txt -l foo.txt

        adsmb dir -s sysvol -mT

        adsmb dir -s homedrive -mT -r krusty\library -n *

        adsmb print -h myserver -s sharedPrinterName -l <-|foo.txt>