* rename manual to active directory manual
* rename getting started to active directory
* update titles and descriptions
* first draft of non-AD getting started
Note: I have images but did not yet include them in the commit history. No need to bloat the repo if those steps will be invalidated by a new installer
* update draft
* update links for new paths
* Update based on review feedback
* update config reference
* Apply suggestions from code review
Co-authored-by: Paul Gottschling <paul.gottschling@goteleport.com>
* post-review edits
* note non-AD as enterprise feature
* expand manual AD process adminition
* Apply suggestions from code review
Co-authored-by: Zac Bergquist <zac.bergquist@goteleport.com>
Co-authored-by: Paul Gottschling <paul.gottschling@goteleport.com>
* disable default services for Desktop node
* document cli access, clarify non-AD listing of hosts
* add join token for new node
* update screenshot for new UI
* copy edit...
Based on https://github.com/gravitational/teleport/pull/19311\#discussion_r1095187559
* name and link for windows exe
* Update download link
* note zip format
---------
Co-authored-by: Paul Gottschling <paul.gottschling@goteleport.com>
Co-authored-by: Zac Bergquist <zac.bergquist@goteleport.com>
* Add port number to cloud address examples for proxy server
* fix port example
* Include 443 port in cloud proxy examples
* use 443 instead of 3080 for cloud examples
* Organize docs guide sections chronologically
This change aims to make docs navigation easier by organizing some docs
sections according to the sequence of steps a user would take to set up
Teleport.
The current docs organization uses a variety of categories and schemes
to organize the docs. For example, there is a "Home" section that
includes the Changelog, Installation page, and Getting Started guides; a
"Setup" section that includes references and admin guides; and
edition-specific sections (Enterprise, Cloud). For a user who is setting
up Teleport--or who has already done some setup work and wants more
advanced instructions--it's difficult to know where in the docs to find
the right information.
This change organizes our how-to guides into the following categories
that describe the process of setting up Teleport:
- Try out Teleport
- Deploy a Cluster (including choosing an edition)
- Configure Access (including SSO, RBAC, and Access Requests)
- Manage your Cluster (admin guides, operations, etc.)
- Use Teleport (this section already exists)
I moved the Reference section after this chronology, since users can
access the reference guides anywhere in the setup process.
As part of the change, I have also moved the content from the
"Enterprise" and "Cloud" sections into "Deploy a Cluster", since this
content has to do with how to deploy a specific edition of Teleport.
Note that this change does _not_ attempt to reorganize our
protocol-specific sections. While adding resources is part of the
Teleport setup process, we have a lot of content in our
protocol-specific sections, and moving it all into a single section
related to adding resources to a cluster would (a) exceed the maximum
depth for subsections in the nav bar and (b) cause more confusion than
it alleviates.
* Respond to PR feedback
- Create a "Compliance Frameworks" section of "Configure Access" with
the FedRAMP and SOC 2 guides
- Rename "Use Teleport" to "Connect your Client"
- Move the database GUI client guide into "Connect your Client"
* Add redirects
* Fix linter issues
* Edit tctl instructions to clarify remote login
Closes#11464
- Ensure that all example tctl commands are accompanied either by
instructions to log in to the cluster or the tctl.mdx partial.
- Edit the guides in the Architecture section to remove notes that
tctl can only be used locally to the Auth Service.
- Edit the user-client-rereqs partial to mention tctl for all
editions, since you can log in to tctl remotely for all editions.
Not editing guides where:
- tctl is run via kubectl exec
- tctl is not mentioned in a code block, i.e., only in passing, and
a reader isn't expected to run the command on their own while
following the guide.
- The user is already expected to run tctl on the Auth Service. The
docker-compose Getting Started guide is an example of this.
* Respond to PR feedback
- Provide more context on authenticating with tctl in the CLI reference
- Update the link to more information re: tctl in the architecture
overview, and indicate that tctl users must authenticate.
- Minor tweaks.
* Respond to PR feedback
- Rephrase the authentication paragraph in the Architecture Overview.
In the future we'll move desktop access to a separate CA, but for
now Windows certs are generated with the user CA, so Active Directory
will need to be updated to trust the new certificate when a rotation
takes place.
By default, any authenticated user can add a workstation to the
Active Directory Domain. Best practice is to restrict this ability,
which is worth mentioning here since Teleport can automatically
discover desktops from LDAP.
* Update desktop access docs for 9.0
- Remove admonition about being in preview
- Add audit events listing
- Break reference.mdx up into separate pages
* Update tile icons
* Address review suggestions
* Another review pass
* Mention Teleport Cloud in some of our guides
- Mention Teleport Cloud in the Desktop Access guide
prerequisites
- Minor style tweak to the K8s Agent guide
- Add a Cloud compatibility note to the Kubernetes cluster
guide
- Make Cloud compatibility more explicit in the multiple-clusters
guide
- Clarify the EC2 tag guide's relationship to Cloud (also add some
general clarity tweaks)
* Respond to PR feedback
* update rfd
* Adds a TDP Error message
* touching up logging and error logic
* Centralizes tdp error handling
* removes tdp level error handling from client.go to avoid making major structural changes which may overlap with other existing work
* fixes spelling
* separates logging from tdp error messages
* minor docs improvements
* fixing log
* Recommend a highly available LDAP endpoint.
Early versions of our docs were worded in such a way that suggested
pointing Teleport at a single domain controller, which would result
in issues if a DC goes down for maintenance or due to error.
We also used to make insecure LDAP connections on port 389, and then
upgrade them using a STARTTLS operation. This is no longer supported.
Fix both of these issues by recommending a highly available LDAP
server and removing references to port 389.
* Add note about direct vs IoT mode
* Move the desktop config reference to a shared includes file
This will prevent the desktop access config examples from diverging
in different parts of the docs.
Additionally, simplify the example in the getting started guide,
as the goal of that guide is to get up and running quickly, not
to provide an exhaustive reference of all the configuration options.
* adds necessary line to powershell script and touches up the docs
* touch-ups
* Updates README to the settings that I thought would do the trick. Just tested with these and RDP is timing out for me.
* CR
* CR
* adding warning about the firewall rules mysteriously dissapearing on us and an instruction to use gpupdate.exe
* Switch GPO creation to powershell
* using local file notation
* fixing comments
* fixing mdx errors
Co-authored-by: Zac Bergquist <zmb3@users.noreply.github.com>
* Refactor component heartbeat callbacks
Consolidate the OK/degraded broadcasts so the same logic isn't
duplicated for each component.
* Periodically update discovered desktops
Fixes#8644
* Allow customizing the desktop search
With this change, we support a discovery base DN other than '*',
and add support for further filtering the results with additional
LDAP filters.
Additionally, we filter out group managed service accounts, which
show up in LDAP searches for (objectClass=computer), despite not
being comptuers. (This is mostly harmless, as the service accounts
aren't present in DNS, so Teleport just ignores them. It does, however,
log a DNS error message that could be confusing, so we explicitly
filter these out just to be safe. This was discovered when testing
on AWS managed AD, which creates a gMSA for DNS.
* updating docs with service account tutorial
* minor corrections
* Apply suggestions from code review
Co-authored-by: Zac Bergquist <zmb3@users.noreply.github.com>
* wording changes based on CR
* minor changes and fixes and adds updated photos with new naming convention
* Updating documentation
* updating gpo instructions to actually make sense
* nits
* adding instructions for exporting ca
* removing unhelpful screen shot
* Fixes quotes and updates to LDAPS
Co-authored-by: Ben Arent <ben@goteleport.com>
* clarifying comment
Co-authored-by: Zac Bergquist <zmb3@users.noreply.github.com>
Co-authored-by: Ben Arent <ben@goteleport.com>
* Connect to LDAP on port 636 (LDAPS)
Rather than connecting to LDAP on the insecure port and attempting
to upgrade the connection to TLS, simply connect on the LDAPS port.
* WIP
* check connection state
* check connection state
* printing certs
* confirming cert verf fails
* checkpoint
* updates config and new ldap client to make use of ldaps
* change VerifyCA to SkipVerifyCA
* checking for proper certificate in applyWindowsDesktopConfig
* fixes yaml value
* CR
* error wording change
* allow the user to use the system cert pool
* var change
* removing todo and renaming some fields
* refactors error messages and simplifies logic
Co-authored-by: Zac Bergquist <zac.bergquist@goteleport.com>
This approach avoids the need to put sensitive credentials in the
teleport config file, which is often shared for examples, testing
and troubleshooting purposes.
* Desktop Access documentation
First draft of the Desktop Access docs. This is for Beta and has the
warnings on every page to make that clear.
* Apply suggestions from code review
Co-authored-by: Isaiah Becker-Mayer <isaiah@goteleport.com>
Co-authored-by: Isaiah Becker-Mayer <isaiah@goteleport.com>
Zac Bergquist